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Language (VRML), the model is an interactive 3D application composed of hundreds of 
topographic tiles linked together to form a mosaic of the bay. Low-resolution tiles are 
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Important contributions include a naming convention for autogeneration of 
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eXtensible Markup Language (XML), demonstrated use of the GeoVRML Working 
Groups proposed QuadLOD node, and a preliminary 3D navigation icon for terrain 
interrogation and wayfinding. Terrain data was produced from registered, smoothed and 
subsampled bathymetric sonarscan results. Because the model is geo-referenced with the 
Universal Transverse Mercator (UTM) coordinate system, a user can easily add scientific 
content or data to a selected location of the MBNMS in a manner analogous to adding 2D 
content to an HTML page. Thus, the user can place 3D content anywhere in the 
MBNMS in geographic context merely by specifying the geographic coordinates and 
depth of the content in standard VRML syntax. 

Future work includes improvement of metadata interoperability, navigation icon 
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I. INTRODUCTION 

A. BACKGROUND 

This thesis investigates how the Virtual Reality Modeling Language (VRML) can 
be used to model the seafloor topography of the Monterey Bay National Marine 
Sanctuary (MBNMS). By creating a topographic model of the MBNMS using VRML, a 
three-dimensional representation of the sanctuary can be accessed over the World-Wide- 
Web (Web) by anyone using a VRML-enabled web browser or standalone VRML 
viewer. A VRML-enabled browser means a browser configured with a VRML plug in 
such as Cosmo Player for PCs (Silicon Graphics, 98). Rapid recent progress in this field 
means that many new opportunities are available. 
B. MOTIVATION 

Numerous scientists and researchers are collecting data and building 
environmental models about Monterey Bay. Regional research partnerships using a 
Large Scale Virtual Environment (LSVE) for Monterey Bay will make it easy for 
scientific content about Monterey Bay to be placed and accessed online. Building a 
Monterey Bay terrain model is a dramatic way to encourage scientists to their work in 
three-dimensional (3D) space and on the Web. New insights and new research 
collaborations are likely. A new paradigm for publication of scientific data and analytic 
results is possible. 
Cc. OBJECTIVES 

The goal is to make the addition of a user-selected portion of MBNMS terrain in a 


3D VRML scene as easy as adding a background image toa 2D HTML page. Thus, it is 


hoped that this effort will make it easy for scientific content about Monterey Bay to be 
placed and accessed online, 1n a 3D geographic context. 

Although many scientists are conducting research in Monterey Bay, bathymetric 
terrain scenery is not easily available. VRML makes 3D graphics accessible to any 
desktop. Constructing a LSVE for Monterey Bay may dramatically enhance ongoing 
regional research collaborations. An additional objective is for the model to support 
variable resolutions of gridded data. "Variable resolutions" essentially means that as a 
viewer gets closer to terrain, the resolution of the terrain increases to provide superior 
granularity. 

D. THESIS ORGANIZATION 

The remaining chapters of this thesis are organized as follows. Chapter II 
provides the background for the effort, introduces a few cartographic concepts, and 
touches on some related work being done. Chapter III presents the problem statement 
and covers design considerations for a feasible solution. Chapter IV provides a look at 
bathymetric data sources and describes the gridding process used to create simple gridded 
text data files. Chapter V shows how these elevation grid terrain text files can be 
processed by a Java program to produced VRML world files. Chapter VI discusses the 
specific VRML constructs produced by the Java programs that implement the MBNMS 
terrain model, including 3D navigation/information icons. Chapter VII considers 
experimental results, examines user access, and shows how users can integrate their 3D 
content and MBNMS terrain. Chapter VIII presents thesis conclusions and provides 


recommendations for future work. 


Il. BACKGROUND AND RELATED WORK 

A. INTRODUCTION 

This chapter examines pertinent background work that motivated the construction 
of a terrain model for the MBNMS and introduces the basic concepts of VRML. It also 
discusses other work being done to produce 3D topographic models, and provides a quick 
look at a tool evaluated by the author that creates 3D topographic scenery in VRML from 
elevation data sets. 
B. BACKGROUND 

‘. Monterey Bay National Marine Sanctuary 

Beginning 11 km north of San Francisco's Golden Gate Bridge, the MBNMS' 
extends 260 km south along the California coast to Cambria Rock in San Luis Obispo 
County. The Monterey Bay National Marine Sanctuary contains the nations greatest 
diversity of marine life and habitat. East to west, the sanctuary stretches 152 km and 
holds one of the world's largest ocean canyons: the 10,663 ft. deep Monterey Canyon. 
Thus, this area provides unparalleled opportunities for marine scientists based at nearby 
research institutions such as Moss Landing Marine Laboratories (MLML), Monterey Bay 
Aquarium Research Institute (MBARI), and NPS. Figure 2.1 illustrates the MBNMS 
region. The sanctuary was established to enhance resource protection and preserve the 


natural beauty within its boundaries. 


' More information on the MBNMS is available at http://bonita.mbnms.nos.noaa.gov/ 
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Figure 2.1. Monterey Bay National Marine Sanctuary (MBNMS Web Site, 98) 
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2: Monterey Bay Modeling Group 

Interest in developing computerized processes and models to assist with studying 
and managing the sanctuary led to the formation of the Monterey Bay Modeling Group. 
In 1993, the MBNMS Research Advisory Committee, under the sponsorship of the 
National Oceanic and Atmospheric Administration (NOAA), prepared a research plan 
which outlined the research priorities and management goals for the sanctuary. This plan 
outlined the objectives of the Monterey Bay Modeling Group, an ad hoc group of 
individuals interested in computer modeling and affiliated with various MBNMS research 
organizations, including NPS. Listed among the objectives was the goal for the 
development of a computerized model of the sanctuary (NOAA, 93). The model, it was 
hoped, would ultimately function as an oceanographic scientific database archival and 
retrieval system, which could be overlain on a 3D physiographic representation of the 
MBNMS. The model would be networked for use by scientists, engineers, planners, 
managers, and the general public. Unfortunately this group was only active for two 
years. Recent discussions indicate that technology has advanced sufficiently to enable 
further scientific collaborations. 

os Coordinate Systems Used 

In terms of latitude and longitude, the MBNMS occupies a square region between 
35°30' North and 38° North latitude, and 123°15' East and 121° East longitude. Since 
latitude and longitude are commonly used measures, they are included in the model's 
metadata and file-naming convention. Universal Transverse Mercator’ (UTM) 


coordinates, which specify a location as a distance north (Northing) and east (Easting) 


? A good explanation of the UTM coordinate system is available at: hitp://geography.tqnm/msub14.htm 


from a zone's meridian mcasured in meters, are also frequently used in cartography. In 
terms of the UTM system, the MBNMS lies between Northing coordinates of 
3.940,000m to 4,200,000m, and Easting coordinates of 460,000m to 612,000m. Because 
UTM coordinates are in meters rather than degrees, UTM measurements can easily be 
converted to VRML coordinates that are default units in meters. This capability allows 
eridded elevation data and scientific content to be positioned relative to their real world 
location in the MBNMS model. 

4, What is VRML? 

VRML - the Virtual Reality Modeling Language - is a 3D graphics scene 
description language that enables a scene builder to create dynamic worlds and sensor 
rich virtual environments on the Internet. VRML enables users to animate objects in 
worlds, making them move; 1t also enables users to play sounds within worlds, interact 
with worlds and, control and enhance worlds with scripts, or small programs (Ames, et. 
al., 97). VRML provides a standardized, portable, and platform-independent way to 
render dynamic, interactive, 3D scenes across the Internet (Brutzman, 97). 

A VRML file generally ends with extension ".wrl". This file 1s a textual 
description of a3D world. A VRML file contains nodes that describe shapes and their 
properties in the virtual world. These nodes make up the building blocks - VRML 
constructs - which create the 3D scenery in a virtual world. For cartographic models 
such as this project, one of the principal VRML constructs 1s the ElevationGrid node, 
which can be used to create a 3D representation of the terrain. The terrain itself is 


described by a data set containing bathymetric depth values. Each sampled depth value is 


associated with a pair of gridded 2D coordinates. An excellent overview of how VRML 
can be applied to cartography can be found in Fairborn and Parsley (97). 
C RELATED WORK 

L: GeoVRML Working Group 

To provide a forum for discussions of the representation and exchange of properly 
geo-referenced data in VRML advance, the GGOVRML Working Group was established. 
One of the forum's goals is to establish VRML as a standard for the representation and 
exchange of 3D geographic and cartographic data. The GGoVRML mailing list is 
maintained as part of the GG@oVRML Working Group of the VRML Consortium by SRI 
International. Figure 2.2 shows the primary issues of interest and concern of the working 


group. 


Coordinate systems - measurement systems including the Geodetic and 
Geocentric systems used to specify locations on the surface of the Earth. 

Time referencing - important for content that is ttmestamped with respect to a 
an absolute reference. 

Terrain representation - imagery usually represented in an array of numbers 
that represent topography in digital form. 

Levels of detail - the hierarchy of resoltions necessary to achieve acceptable 
rendering and performance for a LSVE 


Resolution and accuracy - factors limited by georeferencing VRML worlds to 
a coordinate system and by data storage issues. 

Data interchange - standardized data format and type to enable data exchangge 
and interoperability. 





Figure 2.2. Focus of GGoOVRML Working Group (Iverson, 98) 


Zz. Seamless Solution's Terrain Navigator 
The Terrain Navigator is implemented entirely in Virtual Reality Modeling 
Language (VRML) for use on a low-cost Personal Computer (PC) to enable a content 


developer to integrate highly realistic terrain content with Web pages. This real-time 


interactive visualization software is especially useful for collaborative review of database 
development throughout the design cycle or for entertainment purposes. (Seamless 
Solutions, 98). 

3. SIGGRAPH CARTO Project 

The "Carto Project" began in 1996 as a cross-organizational collaboration 
between the activities of the Association for Computing Machinery's Special Interest 
Group on Graphics (ACM SIGGRAPH) and the International Cartographic Association's 
(ICA) Commission on Visualization. The Carto Project explores how viewpoints and 
techniques from the computer graphics community can be effectively applied to 
cartographic and spatial data sets. This includes exploring how viewpoints and methods 
from cartography can enhance developments in computer graphics; especially those 
associated with the representation of geographic phenomena. These efforts will continue 
into 1999, in conjunction with the time frame of the ICA's Commission on Visualization 
(Rhyne, 98). 

4. VRML Terrain Generators 

Several commercial products exist that can automatically generate VRML terrain. 
To do so, generally these products import a dataset in a prescribed format such as Digital 
Elevation Model? (DEM) and produce export a VRML file via a filter. Rapid Imaging 
Software offers a product called LandForm Gold (RIS, 98) that works like this. A copy of 
this software was evaluated by this author, courtesy of Mike Abernathy at RIS. 
- LandForm Gold is a powerful 3D real-time terrain viewer for the Windows NT/95 


platform. This product allows a user to view geographical data in a three-dimensional 


* DEM files contain data of the elevation of the terrain over a specified area, usually at a fixed grid 


representation and move through the data in a natural and intuitive manner. The program 
accepts numerous file types and allows the user to superimpose an image of the area over 
the terrain. This effect of the image overlay combined with 3D data creates a strikingly 
realistic representation of the terrain, as landmarks and topographical features are 
dramatically revealed in 3D. As mentioned earlier, LandForm Gold also enables the user 
to create VRML models based upon the dataset read by the viewer. Other tools, such as 
Cybertrek (98) and Coryphaeus (98) are also available to create VRML terrain models, 
but were not evaluated by this author. 

= Synthetic Environment Data Representation & Interchange 

Specification (SEDRIS) 

The SEDRIS Geographic Reference Model (GRM) has been proposed by the 
GeoVRML Working Group (discussed later) as a standard for VRML coordinate 
systems. SEDRIS is a reference model and software package that currently supports 12 
different commonly used world coordinate system convention, as well as tools to 
automatically convert reference marks between them. Coordinate system standards 
supported include Geodetic (GDC or latitude/longitude), Geocentric (earth centered 
Cartesian), Universal Transverse Mercator (UTM), and Lambert Conformal Conic 
(LCC). The proposal (GeoVRML, 98) was drafted by SRI International and is 
summarized here. It proposes two levels to employ VRML constructs that implement the 
SEDRIS standards. Level 1 consists of a means of entering geographical coordinates into 
VRML files so that the Cartesian VRML coordinates are generated with respect to a 


geographically referenced local coordinate system. Its use depends only on the 


interval, such as | arc-degree or 7.5 arc-minutes. DEM files are avilable (for a fee) from the U.S. 


Geological Survey at: http://edcwww.cr.usgs. gov/webglis 


availability of a library for converting from geographical coordinates in the GRM into a 
local Cartesian frame. Level 2 consists of an attempt to establish a means for 
automatically managing the relationships between the local Cartesian frames defined in 
Level 1. It is intended as the enabling technology for seamlessly integrating accurately 
georeferenced worlds from a wide variety of sources. Since the constructs contained in 
the proposal are experimental at this time, they were not employed in the MBNMS 
Model. Nevertheless they remain an important area for future work. 

6. Other Existing VRML Terrain Models 

SRI International has developed a VRML terrain model of the Fort Irwin, 
California area. This terrain model has been distributed on CD-ROM and is also 
viewable on the Web (SRI, 98). It uses multiple levels of detail to change the terrain's 
resolution based upon the viewer's distance to the scenery. In 1997 RIS produced a 
model of the San Francisco Bay area (Abernathy, 98). This model was produced to 
convey topographical information to participants in the San Francisco Relay. By 
integrating Global Positioning Satellite elevation data with satellite and aerial imagery, 
the model displayed the terrain the event's course and scenery from a runner's point of 
vlew. 

A simple textured model of Monterey regional terrain is also available at 
http://ece.uwaterloo.ca/vrml98. It provides background for the VRML 98 Symposium 
3D website 
D. SUMMARY 

This chapter explores the related work that preceded or motivated the creation of 


a model for the MBNMS. It places the sanctuary in a geographical context and presents 


the goals of the Monterey Bay Modeling Group. A brief overview of VRML provides 
some basic concepts of this scene-description language. Work related to VRML terrain 
development is considered and VRML terrain authoring tools are introduced - one of 
which is evaluated by the author. Additionally, some existing VRML terrain models are 


identified. 
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Il. PROBLEM STATEMENT 

A. INTRODUCTION 

Although excellent commercial software exists for professional development of 
topographic models (both VRML and non-VRML) in 3D, these tools can be expensive 
and may require data sets to be in a proprietary format. Furthermore, the tools are not 
only necessary to generate the topographic models; they are also often required to be 
present on a user's console in order to view the models. By representing the model in 
VRML, an open solution to the problem of generating topographic data sets and 
subsequently viewing them is obtained. Anyone with a web browser and WWW access 
can potentially interact with the model. This chapter covers the problem of developing 
such an application. It then discusses the advantages of VRML as the basis for 
implementing a solution. Much of the chapter is devoted to an examination of the design 
issues considered in the development of a model solution. 
B. RESEARCH FOCUS 

In the last few years, advances in 3D modeling languages have made it feasible to 
develop the foundation for a 3D model of the MBNMS. VRML in particular enables the 
development of a model that can be viewed over the WWW on any platform with 
Internet access and a VRML enabled browser. In order to place arbitrary research 
information about the MBNMS in a geographic context, a user needs to be able to relate 
MBNMS data with the location the data describes or pertains to in the sanctuary. By 
constructing the model in VRML, a background of the appropriate geographic location 
can be added in a manner analogous to adding a background texture to a 2D HTML page. 


VRML can be geo-referenced with a cartographic coordinated system to support the 


addition of the terrain to ascene. The goal of this thesis is the development of a VRML- 
based model of the MBNMS that 1s accessible over the Web which can enable a user to 
select a portion of Monterey Bay National Marine Sanctuary (MBNMS) terrain and 
easily add scientific content or data to the selected scenery. Thus, the end product will 
allow the user to place 3D content in a geographic MBNMS context. Of primary concern 
when attempting to construct such a model 1s the methodology by which low-resolution 
3D scenery is exchanged for higher resolution scenery, all the while maintaining the 
overarching context of the MBNMS environment with the content added. Because 
bathymetric data of the MBNMS seafloor is available and that data can be gridded to 
various resolutions, and because the model needs to be based upon open-standard VRML 
that is directly authorable, commercial development tools are not required for this effort. 
C DESIGN CONSIDERATIONS 

In addition to being accessible via the Web, a VRML model of the MBNMS 
needs to be navigable and geographically accurate. The units of measurement should be 
in meters and coordinates specified where possible to foster cartographic relation and 
interpretation. The process of switching between resolutions is an important 
consideration that leads to the introduction of two important terms: files and transitions. 
The term files refers to a VRML file covering a certain sized horizontal area that can be 
exchanged for another tile or group of tiles at a different resolution. The term transition 
describes the method of the actual change, 1.e., the mechanics of the switch. Thus a tile 
undergoes a transition from one resolution to another. The method used for transiting 


between resolutions has dramatic performance implications. 
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Figure 3.1. Tile Transitions 


1. Transitions Considered 


The effectiveness of transitions to switch between higher and lower resolution 


tiles is not just a function of the mechanism used. It 1s also dependent upon file download 


time (which is a function of file size and bandwidth) and platform rendering speed. 


Figure 3.1 illustrates the transition schema. To minimize bandwidth requirements, 


multiple resolution tiles arranged in a tree hierarchy can be used. Thus, only low- 


resolution tiles need to be loaded initially. As the viewer gets closer to a region of 


interest, the lower-resolution tiles are switched out with higher-resolution tiles, which are 


downloaded as needed. Minimal level of detail (resolution) also aids in platform- 


rendering speed. Transitions can be considered to be of three types: "SwapTile," 


"QuadTile" and "QuadSwapTile." The three types are illustrated in Figure 3.2. 
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a. “SwapTile" Transition 

This transition swaps a single low-level tile of given area for a single tile 
of twice the resolution with the same area. Thus, there 1s a one-for-one tile exchange 
when this transition occurs. 

b. “QuadTile" Transition 

This transition trades a low-level tile of given area for four tiles (a quad) 
that are each the same resolution as the parent tile. The total area of the four tiles covers 
the same area as the single, previously viewed tile. 

reg “QuadSwapTile" T. ransition 

This transition trades a low-level tile of given area for four tiles that are 
twice the resolution of the parent tile. In other words, a quad of high resolution tiles 
switches out one low-resolution tile. This transition 1s equivalent to doing a combination 
of the other two transitions, 1.e., "QuadSwapTile" = ("SwapTile" + "QuadTile"). 
Nevertheless, a SwapTile + QuadTile combination is less efficient than a QuadSwapTile 


transition since additional intermediate files must be loaded. 
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Figure 3.2. Tile Transition Types 


If the user's goal is to gain successively higher resolution, note that the direction 
of the transitions is important. As a region of interest is approached, transitions will tend 
to be toward higher grid/file resolution in combination with smaller tile subdivisions, 1.e., 
upward and leftward on the above two charts. Alternatively, as a region of interest is 
exited, transitions will be downward and rightward as a region of interest is exited. 

2: Transition Chosen 

The "QuadSwapTile” transition was chosen for the implementation of this project 
because its result is a combination of the other two transitions and it offers a scalable 
means of implementing a hierarchy of switching trees. Its concept is also supported by 


an existing VRML construct (discussed in Chapter VI). Thus it can be readily 
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implemented once the terrain tiles are developed. Figure 3.3 displays the design of the 
project using the "QuadSwitch" transition. Nevertheless, the other two transitions, the 
QuadTile and the SwitchTile, remain useful (at least theoretically) to support higher- 
resolution rendering on higher-performance machines, with the dataset quickly 
retrievable via dedicated Internet connections or local disk availability. Future work to 


integrate all three transitions is discussed in Chapter VIII. 
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Figure 3.3. Implementation of QuadSwapTile Transition 


D. SUMMARY 

This chapter describes the nature of the problem that this thesis addresses. It 
discusses some of the advantages to using VRML as the scene description language to 
implement a solution and some of the reasons why existing tools are not required. It 


examines terrain tile-swapping characteristics of design in detail. 
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IV. BATHYMETRIC TERRAIN DATA 
A. INTRODUCTION 

This chapter discusses the data used in the MBNMS Terrain Model. It covers the 
source and processing of the data. It explains how raw, ungridded, topographic data is 
gridded to desired resolutions and how monolithic grids are partitioned into smaller 
sections. It describes how file names are built for gridded data files and explains the 
metadata included with those files. 

B. DATA PROCESSING 

1. Data Source and Gridding Process 

Ungridded bathymetry data, which is simply raw elevation data of the seafloor 
topography, has data points at intervals determined by the sampling rate of various 
oceanographic surveys. The data points equal the depth of the ocean at that sampled 
spot. The database containing the ungridded bathymetric is maintained by the U.S. 
Geological Survey (USGS). The USGS obtained the data by way of the Seabeam-sonar 
oceanographic survey done by the National Oceanic and Atmospheric Administration. 
Moss Landing Marine Laboratories (MLML) obtained a copy of the data (MLML, 98) 
which is now public domain (USGS, 98). 

In order to be useable fora MBNMS Terrain Model, the raw data needs to be 
gridded at an evenly spaced interval (post-spacing) such that each data point 1s a fixed 
distance from each neighbor. Posts refer to the notion that elevation heights at regular 
intervals are similar to posts of different heights spaced throughout a flat field. Thus, the 
data points form a grid at a given resolution. The closer the points are to one another, the 


higher the resolution of the grid. The raw, ungridded dataset for MBNMS comprises one 


large 40 MB file. This dataset can be gridded to various resolutions using the Kriging 
Algorithm.” Using this algorithm as implemented in a GIS program named "Surfer for 
Windows," (Golden Software, 98). Ray McClain of MLML gnidded the entire dataset at 
post-spacing-interval resolutions of 2000, 1000, and 500 meters, respectively. Appendix 
A contains scripts for batch files that accomplish this. This effort effectively created three 
new datasets, each describing the entire seafloor topography of the MBNMS at the 
respective resolutions (McClain, 98). 

Zs Partitioning the Datasets 

Each of the five gridded datasets can be divided into partitions. Each partition 
contains bathymetric data describing a piece of the MBNMS at the gridded resolution. 
The original coordinate system used in Seabeam Survey data is in decimal degrees 
(latitude/longitude) format. However, the coordinate system needed in the final 
partitioned files is UTM. To perform this conversion, MLML developed a script 
(Appendix B) that creates a batch file to input into a geographic information system 
(McClain, 98). This GIS, called "TNTmips" (MicroImages, 98) used the batch file to 
perform the coordinate system conversion and partitioned the datasets as necessary. Table 


4.1 shows the outcome of the partitioning process. 


* Kriging is a method of interpolation which predicts unknown values from data observed at known 
locations. This method minimizes the error of predicted values which are estimated by spatial distribution 
of the predicted values. MLML used a Linear Variogram model with no anisotropy, no 

drift, and a zero nugget effect. 
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Table 4.1. File Partition Characteristics by Resolution for Entire MBMNMS Footprint 


>, How Resolutions Were Determined 

The three resolutions (2000m, 1000m, and 500m) were determined by considering 
the interplay between file size, maximum dataset size and post-spacing resolution 
intervals. Note in that in Table 4.1, above, the file size for any one partition 1s constant 
since the number of posts in all partitions is the same. This occurs because as 
postspacing is halved, the surface area covered by a partition drops to one-fourth the area 
of the previous, higher resolution partition, keeping the number of posts and thus the file 
size constant. The desired top-level (lowest) resolution partition was determined by 
considering download time and area covered by a partition. The maximum acceptable 
download wait for a file was judged to be 30 seconds. On a low bandwidth connection 
then, such as a dial up 28.8 kilobit per second modem, and allowing for throughput 
reduction resulting from data control overhead, the maximum file size could not exceed 
100 KB. Due to the area of the MBNMS, this results in a 2,000m post-spacing top-level 


file, with resolution doubling at each step. 
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C. FILE NAMING CONVENTION 

A critical requirement for automated development of a large-scale database is that 
file names be self-describing in order that both human-readable and machine-readable. 
Therefore, a file-naming convention was developed that included pertinent attributes of 
each file in the file's name. The name specifies the location of the file's data, the 
postspacing, and the data source. Figure 4.1 shows the convention and gives an example 
file name. File naming is a general requirement for Web-based terrain. This convention 


likely has wide applicability. 


File attributes Example , Explanation 


location latitude N353610 North 35°36'10" 
location longitude W 1232629 NV estaliZ a -2O0 7. 
north-south minutes 140 140' = grid height 
east-west minutes 101 101' = grid width 
post spacing, meters 2000 2,000 = post spacing 


data survey SEABEAM source of data 

GRD =text-based grid data file 
file type GRD, WRL, JPG WRL = VRML file 

JPG = image file (texture) 


Example File Name: N353610 .W1232629.140.101.2000.seabeam.wrl 





Figure 4.1. File Naming Convention 
Db. METADATA 

Metadata or "data about data" describe the content, quality, condition, and other 
characteristics of data. Metadata are used to organize and maintain data, to provide 
information to data catalogs and clearinghouses, and to aid data transfers. Metadata for 


each file is included in the header of each file's data contents. Metadata includes 


Ze 


information about filename, post spacing, grid coordinate parameters, and data processes 
used. A VRML construct developed to encapsulate metadata is explained in Chapter VI. 
E. SUMMARY 

This chapter provides information about the data used that forms the foundation 
of the MBNMS Terrain Model. The origin of the raw data is covered, and the processes 
of gridding and partitioning the data are explained. Also discussed is the reasoning used 
to determine the grid resolutions. The file-naming convention is described, and an 


example file name given. Finally, metadata considerations are noted. 
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Le JAVA PROGRAMS FOR DATAFILE CONVERSION TO VRML 

A. INTRODUCTION 

Two Java programs were written to produce two types of VRML files that 
represent the MBNMS as a 3D model. The first program uses gridded data files provided 
by Moss Landing Marine Laboratories to create the necessary VRML terrain syntax. This 
Java program also automates the tile-positioning process, whereby tiles are aligned to 
correspond with their real-world geographic locations. To link together the terrain tiles, a 
second Java program generates VRML scenes that contain embedded VRML trees which 
select the level of detail appropriate for the scene relative to the viewer's location. 
B. CREATEVRMLTILE PROGRAM: GENERATING INDIVIDUUAL 

VRML TERRAIN TILES 

As noted in Table 4.1, MLML generated a total of 21 gridded data files. For each 
gridded data file, one VRML tile is required. Thus, 21 VRML tiles needed to be 
produced. An automated solution to importing the gridded text data and exporting 
VRML files was produced by writing a Java program. Each VRML tile needed to 
contain certain cross-linking constructs; these constructs are explained in detail in 
Chapter VI. Furthermore, VRML tiles need to be offset, or translated, by the distance (in 
meters) corresponding to the real-world area described by the tile's data. By translating 
each tile by the correct value, each of the five resolution datasets will appear as a nearly 
seamless mosaic. For each resolution, a Java class was produced. Appendix C is a 
CreateVRMLTile Java class that generates terrain tiles using partitions with 1000 meter 
post spacing. Before running the program, a list is constructed which contains the names 


of the gridded data files at a given resolution, with one file name on each line. Fora 


ZS 


given resolution, the partitions that make up the dataset are essentially simple rectangular 
pieces of the MBNMS; they can be assembled in the correct order to make a complete 
representation of the topography at that resolution. In the case of the 500m resolution, 
there are 16 gridded data files in a 4x4 arrangement that comprise the area of the 
MBNMS in a two-dimensional (2D) array. The 16 files can be lined up, one after the 
other, in order of location. For each of the five datasets, with each dataset at a different 
post-spacing, the CreateVRMLTile program does the following: 

1. Read Data File Name 

One at a time, names of gridded data files are obtained and operations to produce 
output based upon that file's data are performed. After getting the name of the first 
gridded data file in the array, that data file is opened so that its contents may be read. 

an Read Metadata 

Next, the program reads the metadata contained in the gridded data file's header. 


A typical excerpt appears in Figure 5.1. 
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# *** Filename *** 
# N353610.W1232629.070.051.1000.seabeam.wrl 
; 

¢ *** Extents Lat/Lon *** 
#NW corner 

# N36d46m29s 

# W123d26m53s 

A 

#NE corner 

# N36d46m30s 

# W122d35m47s 

= 

#SW corner 

# N35d36m10s 

# W123d26m29s 

= 

Hoe COLE, 

# N35d36mll1s 

# W122d36m09s 

¢ 

to" ExStents UIM =** 
a 

#NW corner 

# 4070000 Northing 
# 460000 Easting 
= 

#NE corner 

# 4070000 Northing 
# 536000 Easting 
. 

#SW corner 

# 3940000 Northing 
# 460000 Easting 
= 

+O Corner 


460000 536000 
3.94e+006 4.07e+006 
-3811.36 -1449.41 


# 3940000 Northing 

# 536000 Easting 

it 

$0424 Post Gpacing. «>> 
# 1000 m 

e 

¢ "= Original Surrer Headen se: 
- 

# DSAA 

ee es at 

* 

5 

= 
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Figure 5.1. Typical Metadata Excerpt From Gridded Text Data File 


3: Read Elevation Data 

The program reads the elevation posts which are used to construct a VRML 
elevation grid. 

4. Geographically Position Tile 

The program computes, in meters, the necessary distance to translate the VRML 
tile. This distance is used to geographically position the tile in the MBNMS mosaic. 
Also computed and written to file is the center coordinate of the tile, to be used later in 
the second type of Java program, described later in this chapter. 

ae Write VRML Syntax 

The file-naming convention 1s observed throughout this process. The program 
writes VRML syntax to a file whose name corresponds to the gridded data file. A VRML 
header is produced along with a VRML construct to recreate the metadata of the data file. 
The program then produces VRML constructs that create a navigation icon, an elevation 
grid, and local viewpoints that are tied to the navigation icon. The viewpoints are 
exported to a separate file that is inlined into the top-level scene. 

As each individual terrain tile files is completed, the name of the next gridded 
data file is obtained and the above process repeated until there are no more gridded data 
files to import. 

C; CREATEVRMLTREE PROGRAM: GENERATING LINKING VRML 

TERRAIN TREES 

The VRML construct that performs the switching between resolutions requires a 
tree structure whereby a parent tile can be exchanged for four children tiles. These trees 


are then nested to produce the switching architecture. Two tree levels are required for the 
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overal! application. corresponding to the two top-most resolutions. 1.e., 2000m and 
1000m. Trees do not need to be generated for the highest-resolution tiles, 1.e., the 16 500 
m tiles. A Java program was developed to automate the process of generating the trees. 
Appendix D is a CreateVRMLTree Java class that generates four |.000 m-resolution 
trees. The works in the following manner: 

1. Read Children File Names 

For each of parent generated in the tree, the program reads in the names of the 
files that become the children of that parent and stores those names in an array. 

2. Construct Parent and Children Relationship 

The program builds the tree structure by extracting from the array the proper 
children for that tree and computes the parent's name based upon child!'s name. The 
program then reads the center VRML coordinates of the parent tile, which were exported 
to file as a result of running the tiling program described in section B of this chapter. 

3. Write VRML Syntax 

Using the information stored from the above procedures, the program then wntes 
the VRML syntax that creates the file that contains the tree that corresponds to the tile for 
that level of resolution and location. One tree consists of one parent and four children. 
The process is then repeated until there are no trees left to create for the given resolution. 
The overall process 1s repeated again at the next post-spacing resolution. 
D. SUMMARY 

This chapter describes the process of generating VRML syntax. Two Java 
programs are introduces that automate the process of generating VRML syntax. The first 


program reads gridded data files, selects the proper latitude-longitude area, and exports 
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VRML terrain syntax to create the tile structure of the MBNMS mosaic. The second 
program creates VRML syntax to create files that contain VRML constructs, which select 


a level of detail appropriate for the scene relative to the viewer's location. 
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VI. VRML SCENE DETAILS 

A. INTRODUCTION 

This chapter describes the VRML constructs contained in the two sets of VRML 
files that together comprise the MBNMS Terrain Model. The first set of files, the terrain 
tiles, contain the VRML nodes that create the actual geometry of the shapes in the scene. 
The second set of VRML files, the terrain trees, contain the VRML nodes that acts as a 
switch to trade a low-resolution parent tile for a group of higher resolution children tiles. 
B. TERRAIN TILES 

For a given resolution, many terrain tiles make up the entire MBNMS. Table 4.1 
summarizes tile file size and inventory. Terrain tiles are a textual description of a virtual 
seafloor region. Appendixes E and F are an example terrain tile and scene graph, 
respectively, for file N353610.W1232629.070.051.1000.seabeam.wrl. Terrain tile 
constructs are explained below. 

1. Metadata 

A Metadata prototype node has been proposed (Lipkin, 98) which contains 
pertinent information relating to the contents of a VRML scene. For this project, 
metadata includes authorship, data origin, geographic coordinates covered by tile, and 
other relevant tile-specific information. Implemented using VRML's EXTERNPROTO 
facility, the node permits the Metadata node information to be contained in a string 
written in Extensible Markup Language (XML) format (XML, 98). Since this exposed 
field contains XML code in-line as well as the location of an XML document (containing 


the same metadata) the Metadata node allows easy access to the metadata contents. 


As far as possible, the XML keys and key values used correspond to the Dublin 
Core Metadata Element Sct, a 15-element set intended to facilitate discovery of 
bibliographic information and electronic resources (Weibel, 98). Also considered in 
determining the key/key value pairs was the Federal Geographic Data Committee 
Metadata Standard which requires federal agencies to document the data that they 
produce beginning in 1995 (FGDC, 94).° Using these references as a guide, the XML 
keys for the MBNMS model were developed. The keys (with example key values) are 
shown in Figure 6.1. These key/key value pairs also appear inlined in the final VRML 
file (e.g., N353610.W1232629.070.051.1000.seabeam.wrl. in Appendix E) and in the 
corresponding (XML file N353610.W1232629.070.051.1000.seabeam.xml) in Appendix 
G). Because of the Metadata node's recent availability, it is not a functioning node in the 
MBNMS model. However, the syntax for a potential functioning node is provided in 
each terrain tile along with the actual metadata. Extensive additional work is expected in 
the funtionality of Metadata nodes, as well as in widespread application of metadata 


key/key value conventions in terrain data files. 


> An excellent example of a NOAA implementation of the FGDC standard can be found at 
http://www.csc.noaa.gov/metadata/text/seaview_metadata.html 


Key = ''Key Value" 


Title = "Monterey Bay National Marine Sanctuary Terrain Model 
Subject = "VRML Terrain Model" 

Pulication Place = "Monterey, California" 

Publication. Date = "1998" 

Creator = "Greg Leaver" 

Contributor = "Don Brutzman and Ray McClain" 

Originator = "Naval Postgraduate School" 

Data_Source = "NOAA Seabeam Survey" 

Data_Format = "Surfer DSAA Export" 

Datum = "NAD83" 

Ellipsoid = "GRS 1980" 

UIM: Zone = "10" 

North Bounding Coordinate UTM = "4200000 N" 

South Bounding Coordinate UTM = "3940000 N" 
West_Bounding Coordinate UTM = "460000 W" 
East_Bounding Coordinate UTM = "612000 W" 
Northwest_Bounding Coordinate Latitude = '"N37d56m4" 
Southwest_Bounding Coordinate Latitude = "N35d36m1" 
Northeast_ Bounding Coordinate Latitude = "N37d56m2" 
Southeast_ Bounding Coordinate_Latitude = "N35d35m5" 
Northwest_Bounding Coordinate Longitude = "W123d27m1" 
Southwest_Bounding Coordinate_Longitude = "W123d26m2" 
Northeast_Bounding Coordinate_Longitude = "W121d43m3" 
Southeast Bounding Coordinate_Longitude = "W121d45m4" 
maxElevation = "6.50001m" 

minElevation = "-3808.92m" 

postSpacing = "2000m" 





Figure 6.1. Example XML Keys and Key Values Used in Metadata Node. 
Z Positioning 
A pair of Transform nodes is used to laterally position each tile to its correct 
geographic location in the MBNMS. Thus all the tiles for a given resolution can be 
positioned to form a mosaic of the bay. Thus three complete mosaics have been 


produced, for post-spacing resolutions of 2000, 1000, and 500 meters, respectively. Each 


U2 
o>) 


tile file has a single corresponding Transform node referenced to the local origin of the 
UTM coordinate system, which occurs at the northwest corner of the MBNMS. The 
topmost linking file has the transform that moves the entire geometry set to the proper 
UTM coordinates of the northwest-corner of the origin, 1.e., 4,200,000 meters Northing, 
460,000 meters Easting. 

om Navigation Icons 

To enable a user to easily navigate the model a Transform node is defined as a 
Navigation Icon. This node was constructed by inlining and grouping various shapes. 
Anchor nodes are defined within the marker to permit the viewer to select from four 
different viewpoint orientations from the perspective of that tile: north, south, east, and 
west. The icon also uses a LOD node to switch between high, medium, low, and zero 
detail shapes depending on the viewer's perspective to the marker. Additionally, the icon 
provides information about the location it corresponds to by specifying the position in 
UTM coordinates. An example icon is shown in Figure 6.2. WRML code for the icon 


appears in file N353610.W1232629.070.051.1000.seabeam.wrl in Appendix E. 
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4070000 N 
536000 E 





Figure 6.2. A Navigation Icon. 


4. Elevation Grids 

Each VRML tile has an ElevationGrid node, which simulates the topographical 
features of the geographical region covered by the gridded data file. An example 
elevation grid is shown in Figure 6.3. Example code appears in file 


N353610.W1232629.070.051.1000.seabeam.wrl in Appendix E. 





Figure 6.3. A Single Elevation Grid (File N353610.W1232629.070.051.1000.seabeam.wrl) 
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2: Textures 

Each VRML tile has a corresponding JPEG image for a texture. The textures 
were generated by MLML (McClain, 98) along with the gridded data files. Each image's 
area corresponds precisely with the area covered by the grids and follows the file-naming 
convention. Example code appears in file. 
N353610.W1232629.070.051.1000.seabeam.wrl | in Appendix E. These particular 
textures use a false-coloring technique that maps depth to pixel color. Alternate texture 
images might easily be substituted. This 1s an important area for future work. 
C. TERRAIN TREES 

Terrain trees contain the framework for switching between a low-resolution 
parent tile and four higher-resolution children tiles. These files do the mechanical work 
of switching but contain no constructs to create scenery. Appendixes H and J are an 
example terrain tree and scene graph, respectively, for file 
N353610.W1232629.070.051.1000.seabeam.wrl. Terrain tile constructs are explained 
below. 

1. Switching 

To switch between different tile resolutions, the EXTERNPROTO QuadLOD 
node (Reddy, 98) is employed. A detailed description of the QuadLOD node is beyond 
the scope of this thesis, but a general overview is provided here. In short, Reddy's node 
uses a location-to-camera proximity sensor to control the switching between a parent tile 
and four (quad) children tiles. Additionally, the quad is not fetched until the proximity 
sensor fires, conserving bandwidth. Also, tiles not within a certain bounding box are not 


drawn, improving browser-rendering speed. File caching and release has also been added 
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to improve performance. For these reasons, the QuadLOD node was chosen to form the 
basis for the QuadSwap Tile switching methodology that the MBNMS model depends 
upon. The values used to control the QuadLOD node's proximity sensor are shown in 
Table 6.1. These values are implemented by invoking the QuadLOD node as shown in 
the code excerpt in Figure 6.5, and also appear in Appendix H in file 


N353610.W1232629.070.051.1000.tree.wrl. 






Resolution Transition From Low» ai 
to High s | & 
; Gow ihn reversible) 













igus. 


2,000m / 1000m 152,000m 100,000m 260,000m 
1,000m / 500m 76,000m 50,000m 130,000m 


Table 6.1 QuadLOD Node Proximity Sensor Values 





QuadLOD { 
parentUrl "1000m/Tiles/N353610.W1232629.070.051.1000.seabeam.wrl" 
child] Url "500m/Tiles/N353610.W1232629.035.025.0500.seabeam.wrl" 
child2 Url "500m/Tiles/N353613.W1230119.035.025.0500.seabeam. wrl" 
child3 Url "500m/Tiles/N361 123.W1230120.035.025.0500.seabeam.wrl" 


child4Url "500m/Tiles/N361120.W1232641.035.025.0500.seabeam.wrl" 
parentCenter 38000 0 195000 

parentSize 76000 10000 130000 

switchSize 76000 50000 130000 





Figure 6.4 QuadLOD Excerpt (File N353610.W1232629.070.051.1000.tree.wrl) 

2: Viewpoints 

Viewpoint nodes are located in the top-level tree. Viewpoints are defined and 
named to correspond to uniform resource locations (url) specified in Anchor nodes 
embedded in the Navigation Icons described in the Terrain Tiles section, above. 
Although four viewpoints correspond to each tile, the syntax for the viewpoints is not 


located in the tiles or the individual trees. Instead all viewpoint nodes are located in the 


a] 


top-level 2000m terrain tree file, (1.e., file mbnms.wrl). This 1s because in order to 
maintain the switching integrity of the nested trees, the top-level file must always be 
specified as the url in the browser's netsite window. 
D. SUMMARY 

This chapter explains the structure of the VRML files that make up the MBNMS 
Terrain Model. The terrain tiles are gridded adjacent scenes that contain VRML 
constructs to enable navigation, tile translation, and elevation grid and texture rendering. 
The terrain trees provide the mechanism needed to switch between levels of detail. The 


top-level tree contains viewpoints, while the Navigation Icons point to those viewpoints. 
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VII. EXPERIMENTAL RESULTS 

A. INTRODUCTION 

This chapter presents results obtained in the implementation of the terrain model. 
It takes a look at the structure of the database and the size of the datasets. Next, the 
performance of the model is measured by timing how long it takes to render resolutions 
on two different machines. A section on user access and navigation provides the web 
address and user information on how the model can be accessed and navigated. The final 
section discusses how the model is georeferenced with the UTM coordinate system and 
shows how a user can add content to the MBNMS scene by taking advantage of this 
georeferencing. 


B. MONTEREY BAY TERRAIN MODEL DATABASE 


The directory structure of the model is illustrated in Figure 7.1. 


MBNMS Terrain Model 





Table 7.1 gives the detailed characteristics of terrain tiles, by resolution 
(subdirectory) while Table 7.2 gives the detailed characteristics for the terrain trees, again 
by resolution. The directory structure of the images.and XML datasets mirror that of the 


terrain tiles dataset. 
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1000m 9,880,000 km? | 3,952,000 km? | 51-67 KB 239 KB 
2,470,000 km? | 3,952,000km? | °1-6/KB | 959 KB 


Total Cumulative Size of Tile 
Datasets 






Table 7.1. Terrain Tile Dataset Characteristics 
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Table 7.2. Terrain Tree Dataset Characteristics 


Ge PERFORMANCE RESULTS AND USABILITY TESTING 

Currently, the MBNMS Terrain Model can be accessed by any VRML browser. 
However, going past the top-level low-resolution (2000m post-spacing) entry file is only 
possible using a PC or Macintosh. This 1s because the model uses Script nodes that 


interface with Java class files. Currently, only VRML browsers designed for PCs follow 
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the VRML 97 specification as it pertains to Java in Script nodes (Brutzman, 98). 
Therefore, the model currently does not show higher-resolution tiles with Cosmo Player 
under IRIX (SGI) because it does not support Java in the Script node. This limitation is 
expected to be temporary since all VRML used in the MBNMS model is compliant with 
the VRML 97 specification (VRML 97, 97) 

1. Performance Aids 

a. Vertical Exaggeration. 

Even though VRML renders geometry in 3D, it helps to exaggerate the 
depth ona 2D screen. Increased vertical relief can accomplish this. The MBNMS 
Terrain Model has a vertical exaggeration of one. Figure 7.2 shows how vertical 
exaggeration can be applied, albeit at a loss of scale and registration with any other 
associated object geometry. Figures 7.3 and 7.4 show example differences in vertical 


exaggeration. 


Transform { 
scale 1 3 1 # applies non-uniform scaling (3:1) along vertical-axis (depth) 


children Inline {url " N353610.W1232629.070.051.1000.seabeam.wrl" } 





Figure 7.2 Applying Vertical Exaggeration 





Figure 7.3. 3:1 Scaling Example (File N353611.W1223609.070.051.1000.seabeam.wrl) 
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Figure 7.4. 1:1 Scaling Example (File N353611.W1223609.070.051.1000.seabeam.wrl) 


b. Reducing File Size by Rounding 
File size of terrain tiles is reduced by 30 - 40 % by using integers for 
bathymetric depth values rather that floating point numbers. In an oceanic environment 
with depths in thousands of meters, 0.5 meters of error due to integer rounding is an 
acceptable figure considering the payback in download and rendering speed that results 
from substantially smaller files. Since maximum resolution of the underlying smoothed 
dataset ranges from 5m to 10m, this is a safe assumption. 
Z. Performance Results 
The MBNMS contains three levels of resolutions, 2000m, 1000m, and 500m. 
Table 7.3 shows the rendering performance on two different machines, with time as the 
performance measure. Time is measured from the moment a proximity sensor 1s tripped 
from one resolution (to load the next resolution) until the next resolution is drawn on the 
screen. Measurements are for the exchange of one parent tile for four children tiles and 
are not cumulative. On slower processors, or those without 3D-graphics hardware 


acceleration, the model renders reasonably quickly at the 2000m and 1000m resolutions. 
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But on these platforms the 500m resolution tiles are slow to render. Performance was 
relatively unaffected by whether or the copy was on a local machine or fetched over a 
network. Much further user testing and optimization is possible. Future implementation 
of SwapTile and QuadTile mechanisms as described in Chapter IV can likely provide 
good speedups across all platforms. Nevertheless, we believe that the current approach 
already provides excellent scalability, since high-resolution files need only be retrieved in 


close proximity to the viewer. 
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Table 7.3. Rendering Time for Resolutions 





D. USER ACCESS AND NAVIGATION 

The MBNMS Terrain Model is available over the Web at hittp:// 
www. stl nps.navy.mil/~auv/leaver/MBNMSterrain/2000m/Trees/mbnms.wrl. The model is 
compatible with Cosmo Player (minimum version 2.1). The entry-level viewpoint 


presents the top-level scene shown in Figure 7.5. 
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Figure 7.5. Entry Viewpoint of MBNMS Terrain Model 


A navigation icon is positioned at the center of the tile in the screen foreground. 
Navigation icons are switched in and out together with corresponding terrain tiles. Each 
tile has a unique navigation icon that provides four relative viewpoints. The initial top- 
level scene is at the widest possible resolution (2000 m). The viewer can determine this 
by positioning the mouse over any of the navigation icon's four compass headings. This 
causes the current level of resolution (that the navigation icon is at) to be displayed I at 
the bottom of the browser's window. By clicking on an icon direction label a viewpoint 
can be selected. Selecting the viewpoint causes the viewers position to change to the 
direction of the compass heading chosen, at a perspective just above the navigation icon. 
Navigation icons are positioned at a tile’s center on the boundary of the proximity sensor 


that controls the switch between resolutions. That is, if the viewer flys beneath or drops 













7 - 7 
7 - ; _ 
_ ° oe : 
- : 
b - 
= — 7 ia) a 7 a 
a - _ — > 
7 ‘ 
_ i . aa 
: 7 ) : > : s : 
7 | 
) - 
: : : - 
7 2s Vs : 7 
a 
7 ‘ v sf 7 = = 
a aa : - 
: - ; - a - 
7 7 ’ oe 
a i = 7 _ 
7 ; 
>| 
a : 7 7 
: a ee - 
: ; - 7 
. 7 ; _ ; 
— ; - : ee 2 ; ha 7 ec 
. - 
ge ea | pay = ; . a \- a a 
. . 7 
- aa a : 7) 6 0) re — aes / oa os | ve dul ite A tat ae 
| AD deh Ga eG? om HER TigiAannt @dinng oe is — 7 
rt 
— pis | (Ae Ew: ; ponies 
fe ee er 1 tal irenay ae man 
; 
a 2 O18 HPA A cag IL Melns We His relat af 
a di = 


UY @& specth: 46 one = ea BF. ay aaa  bokenan Do am 
Nid aleyh ees MIF Be Hh LER Oven & fides 4 se om 
os ks a eeu a me ae = nara 0 Oe pA 


pein A wee A ah at An ue! done ses 


7 : — "~ L 7 | 7 


a. 

















below a navigation icon, the next resolution for that tile will be switched in. Thus, a low- 
resolution tile (and the tile's navigation icon) is replaced with four higher resolution tiles 
(and their corresponding navigation icons). An icon can be made to disappear by 
clicking on its sphere. Icons which have been made to disappear can be restored by 
zooming out to a lower-resolution level and then zooming back in to reload the higher- 


resolution level. The icons and switching occurs at the values shown in Table 7.3. 





Table 7. 4 Tile Switching Values (depth) 


FE. EXAMPLE INTEGRATION OF CONTENT 

i, Georeferencing 

The MBNMS Terrain Model's coordinate system is georeferenced to the UTM 
coordinate system. The model is built with the VRML coordinate system origin (the 
point 0,0,0 of the root node) corresponding to the baseline position of Zone 10 of the 
UTM coordinate system, 1.e., 0 m North, 0 m East of Zone 10. The northwest corner of 
the real MBNMS is located at 4,200,000 m north and 460,000 m east (in UTM, 
4,200,000N, 460,000E) of the zone 10 baseline. In VRML, the Terrain Model is 
designed so that North is in the positive x direction, and East is in the positive z 
direction. So, the northwest corner of the Terrain Model is located 4,200,000 units in the 
positive x direction, and 460,000 units in the positive z direction. Thus, in the x-z plane, 


the coordinates of the Terrain Model correspond to the real life sanctuary in terms of the 
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UTM coordinate system. The y-axis represents depth. Figure 7. 6 represents thesc 


relationships. 


+ y 
Elevation 


Object: NW Corner of MBNMS: 
x = 4,005,000 { x = 4,200,000 


-y = depth -y = depth 

z = 536,000 z = 460,000 

Northing = 4,005,000m Northing = 4,200,000m 
Easting = 536,000m Easting = 460,000m 
Depth = bathymetric point Depth = bathymetric point 





Figure 7.6. Georeferencing VRML and UTM Coordinate Systems 


It is worth noting that this two-stage approach to georeferencing was further necessary 
because VRML 97 does not support double floating-point precision. Establishing two- 
step floating-point coordinate conventions, or providing double-precision support are 
important areas of effort for the GGoVRML Working Group. 

De Adding Content 

Since the MBNMS Terrain Model is georeferenced with the UTM coordinate 
system, adding content to a VRML scene in context with its proper location in the real 
MBNMS requires just a few simple VRML statements. As Figure 7.7 shows, content can 
be added in context with the MBNMS that might be at the location of 4005000 Northing 


and 536000 Easting (1.e., N36d11m20s latitude, W122d35m58s longitude). 
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F. SUMMARY 

This chapter describes the detailed VRML construction of the MBNMS database 
and also examines the structure and the size of the datasets. A section on performance 
measures how long it takes for the model to render on two different machines. Also, a 
section on user access and navigation provides the web address to enable a user access 
the model and information on how the model can be navigated. Finally, by 
georeferencing the model with the UTM coordinate system, an example is provided to 


show the user how content to the MBNMS scene can be added. 
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VIIT. CONCLUSIONS AND RECOMMENDATIONS 
A. RESEARCH CONCLUSIONS 

The VRML terrain model of the Monterey Bay National Marine Sanctuary 
consists of numerous terrain tiles, terrain trees, and jpg images to support three levels of 
topographic resolution. Different VRML mechanisrns for switching between resolutions 
have been considered, with the QuadLOD selected as the primary mechanism of choice. 
Relevant findings on issues regarding VRML creation, viewpoints, rendering, and 
georeferencing with content are amplified below. 

1. Generating VRML Syntax 

To build the MBNMS model, preprocessed bathymetric data files are imported by 
a Java program which positions the terrain tiles and terrain trees and exports VRML 
syntax. A prerequisite effort was access to a large GIS database engine (MLML, 98). 
This approach proved to be an effective method of creating VRML files for a large-scale 
virtual environment. 

z Viewpoints 

Extensive experimental efforts to embed native VRML viewpoints in the 
individual tiles failed, for two reasons: self-describing viewpoint names are too long, and 
viewpoints continued to accumulate far past any usable number. 

The current model uses a navigation icon to select viewpoints and to mark 
locations in the VRML world that correspond to real-life locations (e.g., the center of 
each tile). One of the benefits of using navigation icons is that they can be inlined with 
the tile geometry. This allows them to be switched in and out with terrain tiles; 


automatically culling unneeded icons from view along with the icon's corresponding 
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terrain tile. Another benefit is that four viewpoints are attached to the icon to enable easy 
viewer navigation of the model. The viewpoint nodes, while defined in the top-level 
scene, are pointed to from navigation icons that are located in the terrain tiles. 

The viewpoint nodes in the top-level scene contain empty description fields. If 
the description field is empty, viewpoints aren't listed in the browser window. 
Ordinarily, viewpoint descriptions are listed, but with the QuadLOD switching scheme 
utilized by the model, four viewpoints would be listed each time a tile is switched in. 
Unfortunately, the viewpoint list is not culled when tiles are dropped from view or 
switched out, causing the viewpoint menu to be quickly overloaded. The navigation icon 
method solves this problem since the empty description field in the viewpoint node 
prevents the viewpoints from ever appearing in the viewpoint menu. It also frees up the 
viewpoint menu for an author's content-related use. 

S: Rendering 

The MBNMS contains three levels of resolutions: 2000m, 1000m,and 500. On 
slower processors, or those without hardware acceleration, the model renders reasonably 
quickly at the 2,000m and 1,000m resolutions (one or two frames per second). But, on 
these platforms, the 500m resolution is slow to render. This does not seem to be related 
to file size of the terrain tiles or file download delays, but instead seems to be a result of 
too many polygons in the scene. The QuadLOD node does cull tiles that are not visible, 
so it seems the problem lies with too-high resolution tiles in the scene, given the area 
covered by the scene. In other words, there are too few resolution steps nested in the tree 


hierarchy. This probably might be further diagnosed and solved by starting with a lower- 
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resolution top-level scene than the 2000m spacing used, such as 4000 m spacing. 
Resolution can then be increased again by a factor of two each time. 

4. Georeferencing and Content 

The MBNMS Terrain Model, built in the VRML coordinate system, is 
georeferenced to the real sanctuary when mapped in a UTM system. By aligning the 
model to the UTM coordinate system, users are able to place content in context with a 
terrain environment. A few simple VRML statements added to the user's scenes are all 
that's necessary to integrate geometry. However, this content is most likely at a depth 
encapsulated by a high-resolution proximity sensor. As a result, if a user attempts to get 
close to the object to view it in detail, the sensor will trigger, and as mentioned above, 
this high resolution scenery is slow to render on some machines, making accessibility to 
the object problematic. 
B. RECOMMENDATIONS FOR FUTURE MBNMS TERRAIN MODEL 

WORK 

Li. Normal Vectors to Eliminate Tile Seams 

When a quad of higher resolution child tiles replaces a lower resolution parent tile 
seams between the quad of tiles are sometimes noticeable. Although this is expected 
when tiles of different resolutions abut one another, the seams occur even within the 
quad. These tiles - and neighboring tiles of the same resolution - are in fact coplanar 
because they were designed to have the same elevation points at the seams. The problem 
is that normals ° (normal vectors) for the two adjoining tile's edges are computed 


differently and so the edges are shaded differently. This occurs because while the edge 


° Unless explicity specified, normals are computed by the browser. Normals are like arrows pointing 
straight out from a face or an edge, and determine shading. 
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for one tile might face the viewer, the edge for its neighbor might be facing away from 
the viewer. Since each tile has no information about the other, the normals are computed 
independently. To resolve this inconsistency, normals can be preprocessed and explicitly 
included in the node's geometry for a scene. Explicitly specifying normals might also aid 
in rendering speed, as it relieves the browser from the computational effort during initial 
rendering. However, it will increase download time. Note that normals also have a 
visible effect if texture imagery is included. A possible optimization for the next- 
generation VRML specification is to allow definition solely for normals of the edge 
vertices, allowing browsers to calculate internal normals. 

pa Modified QuadLOD Node 

The QuadLOD Node 1s a remarkable node - an efficient algorithm for switching 
tiles that the MBNMS Terrain Model must have for proper operation. However, one 
drawback from employing the current node 1s that when a viewer exits and re-enters the 
node's proximity sensor box, the node reloads tiles already in memory. This causes 
delays in rendering and another fetch for four tiles - whether they are local or over the 
network. Browsers don't seem to be smart enough to yet know the difference, so a 
solution might be a smarter QuadLOD node that turns off its proximity sensor when the 
viewer exits the sensor's box. Such an approach could be coded using static (persistent) 
classes. This would prevent the quad from being reloaded, and would allow a developer 
to include descriptive viewpoints with the tiles that would not be redundantly loaded and 
cumulatively bound to the scene. A separate drawback to using the QuadLOD node is 
that it binds all geometry to the top-level node. For example, to include content in the 


MBNMS, the content must be inlined or nested with the file containing the top-level 
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QuadLOD node. This author was unsuccessful in finding a way to do the reverse - i.e., 
inlining the MBNMS file containing the QuadLOD node with the content. This is a high 
priority shortcoming which needs correction. 

3. Navigation Icons to Control Other Transitions 

This thesis discusses three types of switching. The first is the QuadSwapTile 
method implemented by the QuadLOD node to perform switches automatically. The 
other two (SwapTile and QuadTile) might be good ways for a user to decompose the 
combined functionality of the QuadLOD node by allowing a user to either break a parent 
tile into four children, or to simply trade a low resolution tile for a high resolution tile. If 
the user might control transitions between these two alternatives, perhaps by using a 
control panel attached to the navigation icon that was brought in and out with the tile, the 
user might navigate and transition more easily to the desired resolution. It would also be 
more efficient since the QuadTile switch might let a user continually segment a low- 
resolution tile until the destination is approached and the desired locale needs to be 
"blown up" to a higher-resolution tile. At this ttme a SwapTile transition could complete 
the transitions to high-resolution local small-area tiles, saving all the download and 
rendering overhead that comes with the middle resolutions in the nested hierarchy 
approach. Either or both transition triggers might be attached sensors or anchors on the 
navigation icon already available for user selection. A triggered QuadLOD node could 
be used for the QuadTile transition, while the VisibliiyInline node (Reddy, 98) could 


might be employed to switch tiles in the SwapTile transition. 
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4, Return of the Navigation Icons 

Currently, a viewer can cause navigation icons to disappear by clicking on a 
certain part of them. They disappear by scaling to near zero. The problem with this 
approach is that the viewer can't get them back unless the tile that contains them is 
reloaded. To offer a means of retrieving them, it might be better instead for them to 
become nearly transparent upon user selection rather than to scale down, so that the icons 
are still visible (barely) in the scene. The problem with putting a control panel elsewhere 
(out of the immediate scene) is that the current scene and its geometry will be disrupted 
as QuadLOD node proximity sensors are tripped and new geometry is loaded when 
moving to the viewpoint. 

5. Other MBNMS Model Future Work 

Because the maximum resolution of the underlying smoothed dataset ranges from 
five meters to 10m, it is possible to construct higher-resolution gridded datasets than the 
2000m, 1000m, and 500m datasets generated for this project. Future work includes 
generating higher-resolution datasets from which terrain tiles with post-spacings of 250m 
and 125m tiles can be created. Even higher resolution terrain tiles might be developed as 
well. 

Additional work is also needed to provide functionality for the Metadata node as 
applied in the MBNMS Terrain Model and to improve metadata interoperability. 
C OTHER LSVE FUTURE WORK 

With the amount of digital elevation data available it may soon be possible to map 
the United States asa VRML LSVE. Future work includes an automated mapping of the 


entire DEM database to produce a VRML model of the continental United States. 
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Another item ripe for future efforts is the development or evaluation of tools for 

converting latitude/longitude coordinates into UTM. Still more possibilities exist in 
developing conventions for texture mapping, especially autogenerated textures. Finally, 
future work includes establishing SEDRIS interoperability with VRML terrain models. 
We forsee the day when georeferenced terrain is an expected context for all real-world 


3D scenes on the Web. 
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APPENDIX A: SCRIPTS USED TO GRID DATA SETS 


Surfer Script 1: 


KAEKKKEKKEKKEKE KKK KKK KK KKKK KKK KK KK KKK KK KKK 


' * makegrid.bas 

' * Grids a bathymetric data set 

' * Runs under the Surfer environment 
' * Programmer: Ray McClain 

' * Created: 6/98 

! * 


* 
* 
* 
* 
* 
KAEKKKKRKKEK KKK KKK KKK KK KKK KKK KEK KKK KEKE 


( *kek*%* Tnitialize input and output data files ***** 
DataFileS=InputBoxs ("Enter the data file name", "Make 
Grid’, "CC: \publie vrmli\ batch) 
OutPath$="c:\public\vrml\batch\oututm.grd" 


| **x*%**x Tnitialize Windows app variables ***** 
Set Surf=CreateObject ("Surfer.App") 


[ **%kk* Tnitialize process variables ***** 
Method=1 


' **x*x** Grid the data ***xx*x* 

ast 

Surf.GridData (DataFileS, GridMethod=1,xS1ize=250, ySize=250, Out 
Grid=Out Paths, OutFmt=2)=0 then end 


a 


Surfer Script 2: 


1 KKK KEKEKEKKEKEKEKEKEKEKE KKK KEKE KKK KK KKK KK KKK KEK 


* plotgrid.bas . 
* Extracts tiles from a grid file * 
* Runs under the Surfer environment * 
* Programmer: Ray McClain * 
* Created: 7/98 * 
* * 


KHEKKKKEKE KKK KKK KKK KKK KKK EK 


-_ — = = = = 


print 
print 


| *kk*kkk Tnitialize the external files ***** 
InDataFileS="C:\public\vrml\rev250.grd" 
DataFileS=InputBoxs ("Enter the data file name","Ray's 
Test", "C= \publte \vrmi baton) 


' *&*kkkk Tnitialize the Windows system variables ***** 
Set Surf=CreateObject ("Surfer.App") 


| **xkekke*e Tnitialize the loop variables ***** 
FirstRow=1 

LastRow=131 

1 Oe Ol 


te cece we eS bye roc wainGecOliinins as ates 
for rows=1 to 8 


Fivetco!— 
Lastcol=77 


for scoOus= «1 “CoS 

| ***kkk Create tile filename ***** 
fnsS-ltrims({strs (in) } 
OutPathS=DataFileS+"\"+fn$+"ray250" 


Prune, Ourraris 


Deine "Rar secots= V  birsecot 
print “GascecCol = 1 tastcol 
print) “Hirstkew = |) Faustkow 
print "LastRow = ", LastRow 


| *k*kk*k Extract the tile ***** 
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if 
Surf .GridExtract (InGrid=InDataFileS, rl=FirstRow,cl=FirstcCol, 
r2=LastRow, c2=LastCol,OutGrid=Out Paths, OutFmt=2)=0 then end 


FirstCol=LastCol 
LastCol=LastCol+76 


fn = fn +1 
next 


FirstRow=LastRow 
LastRow=LastRow+130 


next 
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APPENDIX B: SCRIPT USED TO PARTITION DATA SETS 


TNIMips Script: 


# KREKEKKEKEKKEKEK KEKE KRKEKEKEKE KEKE KKEKKKEKEKKKKEKRKKKEKSE 
# * Ll2utm.sml * 
# * Converts bathymetry from Lat/Lon to UTM * 
# * Runs under TNTMips SML environment * 
# * Programmer: Ray McClain * 
# * Created: 5/98 * 
# KERR KEKEKRKEKEEKKE KK KEKE KKK KEKKKKEKEAKEKEKKEKE KKK 
clear () 


# ****x* Open external files ***** 
z fopen ("c:/public/vrml/sbll.asc","r") 
g fopen("c:/public/vrml/sbutm.dat", "w") 


# **kkk Select georeference parameters for source data ***** 
print ("Choose the source parameters.") 
source = GeorefGetParms () 


DLIne \) 
Drane{) 


# **x*x*x*k Select georeference parameters for output data ***** 
print ("Choose the destination parameters.") 
dest = GeorefGetParms () 


caqabelog @ Ure ekask guoy y 


# ***** Tnitialize loop variables ***** 


a = 0 
totalcount = 1 
Countel =«l 


# *xkkxkkk Drocess until end-of-file ***** 
while (a==0) begin 


# ***** Read input data file ***** 
depth = fgetnum(f) 

lat= fgetnum(f) 

lon= fgetnum(f) 


6] 


#} x*kkkx Convert Lat/Lon to UTM 
GeorefTrans (source,lon, lat, dest,east,north) 


# ****x* Write UTM values to output file ***** 
POrincr (og, "sl0.6r 210-6i 47.26 ni" north, east, depen) 


f# **x*xx* Update the process status bar ***** 
COUnEL =" Counel+1. 


if (count1 == 10000) then begin 
prinek a) 

count ) 4-1 

end “#if (countl == 50 


# *kxkee Test for end-of-file ***** 
a = feof(f£) 


totalcount = totalcount +1 
end #while(a==0 


# *xk*x*k Print processing summary ***** 
DEINE) 7ori me |) 

DiI lOral ‘points “Converted — ") totalcount) 
Drie () priate () 

print ("***** Conversion Process Completed *****") 


Heoxae nn CLOSse External Liles: *e%%% 


close (f£) 
close (g) 
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APPENDIX C: CREATEVRMLTILE JAVA PROGRAM 


[eRe eRe ee ESSERE SRERERREERERSRRERRRERARSESRARELASEESSERASSLAESSGAASEESESESLESAESE SS SS 
// Script Name: Createl000mVRMLTile.java 


// Description: Create a VRML terrain tile at 1000m post-spacing 
resolution 


// 

// Author: R. Greg Leaver 

// Advisor: Don Brutzman 

// 

// Revised: 1 September 98 

Ts 

// Notes: Need one class for each post-spacing 
// 

// 

(eee eee REE ESSE SRS ESSER SSSRELRSRSSALRASSBABREBRARSSRERARSSBSSSBREBRBEREESEEBRESLE SSE SS YS 
// 


KKK HK KKK KKK KKK KK KKK KEKE KEKE KEKE KEKE KEEEEEEKEEKEEEKEEKKEKEKEKEKEKEKSE 


import java.io.*; 
import java.math.*; 
public class create1l000mVRMLtile { 
public static void main (String argv [ ]) throws IOException { 
FileInputStream dataSetFile = new FileInputStream 
("1000mGridSet.txt") ; 
StreamTokenizer dataSetTokens = new StreamTokenizer 
(dataSetFile) ; 
String gridName; 


// Create output stream to write viewpoints to file; 
FileOutputStream viewpointOutputFile = new FileOutputStream 
("1000mViewpoints.txt") ; 
PrintStream viewpointOutput = new PrintStream 
(viewpointOutputFile) ; 


// Create output stream to write center of tile values to file; 
FileOutputStream vrmlTreeOutputFile = new FileOutputStream 
("1000mParentCenters.txt") ; 
PrintStream vrmlTreeOutput = new PrintStream 
(vrmlTreeOutputFile) ; 


// Set postspacing and number of tiles: 
int postSpacing = 1000; 
int numberTiles = 4; 


// Determine tile grid side for use in translation field of Transform 
node: 
int sideTiles = (int) Math.sqrt (numberTiles) ; 


dataSetTokens.quoteChar((int) '"'); 


// Initialize translation and dimension values: 
int lastzDimension [ ] = new int [sideTiles] ; 
int lastzTransform [{ ] = new int [sideTiles] ; 
for (int i = 0; i <= (sideTiles-1); i++) { 
lastzDimension [iJ = 1; 
lastzTransform {1i] 0; 


int lastxDimension = 1; 
int lastxTransform = 0; 
int xCounter, zCounter; 
int xDimension = 0; 
int xTransform = 0; 
int zTransform = 0; 
int zDimension 0 


~e ~ 


// Loop for setting z translation value: 
for (zCounter = 1; zCounter <= sideTiles; ++ zCounter) { 


// Loop for setting x translation value: 
for (xCounter = 1; xCounter <= sideTiles; ++ xCounter) { 
dataSetTokens.nextToken ( ); 


// Get data file names one at a time: 
gridName = dataSetTokens.sval; 


// Pass data file name to input stream: 
FileInputStream dataInputFile = new FileInputStream (gridName) ; 
StreamTokenizer dataInputTokens = new StreamTokenizer 
(dataInputFile) ; 


// Variables for data input: 

double minDepth, maxDepth, lowerUTMN, upperUTMN, leftUTME, 
rightUTME, 

centerUTMN, centerUTME; 

String fileName, viewpointName, 

uleftLong, uleftLat, urightLong, urightLat, 

lleftLong, lleftLat, lrightLong, lrightLat, 

uleftUTMN, uleftUTME, urightUTMN, urightUTME, 

lleftUTMN, lleftUTME, lrightUTMN, lrightUTME, 

northing, easting; 


// Set parser flag to # and begin parsing data file: 
dataInputTokens.quoteChar((int) '#'); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
fileName = (String) dataInputTokens.sval.substring (1,42); 
dataInputTokens .nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 


64 


dataInputTokens.nextToken( ); uleftLat = 
(String) dataInputTokens.sval.substring (1,9) ; 
dataInputTokens .nextToken( ); uleftLong 
(String) dataInputTokens.sval.substring(1,10) ; 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); urightLat 
(String) dataInputTokens.sval.substring (1,9); 
dataInputTokens.nextToken( ); urightLong = 
(String) dataInputTokens.sval.substring (1,10) ; 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ) ; 
dataInputTokens.nextToken( ); lleftLat = 
(String) dataInputTokens.sval.substring(1,9) ; 
dataInputTokens.nextToken( ); lleftLong 
(String) dataInputTokens.sval.substring(1,10) ; 
dataInputTokens .nextToken( ); 
dataInputTokens.nextToken( ); 


dataInputTokens.nextToken( ); lrightLat = 
(String) dataInputTokens.sval.substring(1, 9); 
dataInputTokens.nextToken( ); lrightLong = 


(String) dataInput Tokens.sval.substring(1,10) ; 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); uleftUTMN 

(String) dataInputTokens.sval.substring (1,8) ; 
dataInputTokens.nextToken( ); uleftUTME 

(String) dataInputTokens.sval.substring (2,8) ; 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 


i 


dataInputTokens.nextToken( ); urightUTMN = 
(String) dataInputTokens.sval.substring(1,8) ; 
dataInputTokens.nextToken( ); urightUTME = 


(String) dataInputTokens.sval.substring (2,8) ; 
dataInputTokens.nextToken( ); 
dataInputTokens .nextToken( ); 
dataInputTokens.nextToken( ); lleftUTMN 

(String) dataInputTokens.sval.substring(1,8) ; 
dataInputTokens.nextToken( ); lleftUTME 

(String) dataInputTokens.sval.substring (2,8) ; 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); lrightUTMN 

(String) dataInputTokens.sval.substring (1,8) ; 
dataInputTokens.nextToken( ); lrightUTME 

(String) dataInputTokens.sval.substring (2,8) ; 
dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ); 
dataInputTokens .nextToken( ); 
dataInput Tokens .nextToken( ); 
dataInputTokens.nextToken( ) ; 


fl 


fl 
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dataInputTokens.nextToken( ); 
dataInputTokens.nextToken( ) ; 


// Unset parser flag: 
dataInputTokens.ordinaryChar((int) '#'); 
dataInputTokens.nextToken( ) ; 


dataInputTokens.nextToken( ); xDimension = 
(int) dataInputTokens.nval; 
dataInputTokens.nextToken( ); zDimension = 


(int) dataInputTokens.nval; 
dataInputTokens .nextToken( ) 
dataInputTokens .nextToken( ) 
dataInputTokens.nextToken( ) 
dataInputTokens.nextToken( ) 
dataInputTokens.nextToken( ) 
dataInputTokens.nextToken( ) 
dataInputTokens.nextToken( ) 

dataInputTokens .nextToken( ) 

) 
) 
) 
) 
) 
) 
) 
) 


’ 


leftUTME = dataInputTokens.nval; 
rightUTME = dataInputTokens.nval; 


=e © 


upperUTMN = dataInputTokens.nval; 


lowerUTMN 


dataInputTokens .nextToken ( dataInputTokens.nval; 
dataInputTokens.nextToken ( 
dataInputTokens.nextToken ( 
dataInputTokens .nextToken ( 
dataInputTokens.nextToken ( 
dataInputTokens.nextToken ( 
dataInputTokens .nextToken ( 


dataInputTokens.nextToken ( 


« 
e 
e 
e 
e 
es 
* 
* 
e 
e 


; minDepth = dataInputTokens.nval; 
; maxDepth = dataInputTokens.nval; 
// Compute center UTM values: 

centerUIMN (1000000) * ((upperUTMN + lowerUTMN) /2) ; 

centerUTMB = (leftUTME + rightUTME) /2; 


northing = String.valueOf (centerUTMN) .substring(0, 7) ; 
easting = String.valueOf (centerUTME) .substring (0,6) ; 


// Read data and construct initial array from Surfer program export: 


2h ph sige as |G 
int vrmlArray [ ] [ ] = new int [zDimension+1] [xDimension+1] ; 
for (i = 0; i <= (zDimension -1); i++) { 

for (j = 0; j <= (xDimension-1); j++) { 


dataInputTokens.nextToken( ); 
vrmlArray [i] [j] = (int) dataInputTokens.nval; 


} 


// Construct values to geographically translate the tile: 

xTransform = postSpacing * (lastxDimension - 1) + 
lastxTransform; 

zTransform = postSpacing * (lastzDimension [xCounter - 1] -1) + 
lastzTransform [xCounter - 1]; 

dataInputFile.close( ); 


// Compute center of tile for use in creating tree and export to file: 


int xtreeTranslation = xTransform + (postSpacing* (xDimension- 


nO rah 
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int ztreeTranslation = zTransform + (postSpacing* (zDimension- 
nl ae 

vrmlTreeOutput.printlin("\"" + xtreeTranslation + "0" 4+ 
ztreeTranslation +"\""); 


// Create basis for this tile's named viewpoints: 


viewpointName = (gridName.substring(1,7) + "_" + 
gridName.substring(9,16) + "_" + gridName.substring(17,20) + "_" + 
gridName.substring(21,24) + "_" + gridName.substring(25,29)) ; 


// Create output stream to export XML: 

String xmlfileName; 

xmlfileName = (fileName.substring(0,38) + "xml"); 

FileOutputStream xmlOutputFile = new FileOutputStream 
(xml£ileName) ; 

PrintStream xmlOutput = new PrintStream (xmlOutputFile) ; 
// Export XML: 


xmlOutput.println ("## Title = " + "\"" + "Monterey Bay National 
Marine Sanctuary Terrain Model" + "\""); 

xmlOutput.println ("## Subject = " + "\"" + "VRML Terrain Model" 
+ wm) : 

xmlOutput.println ("## Publication Place = " + 
"\"" + "Monterey, California" + "\""); 

xmlOutput.println ("## Publication Date = " + "\"" + "1998" 4 
on) : 

xmlOutput.println ("## Creator = " + "\"" 4+ "Greg Leaver" + 
ie ") ; 

xmlOutput.println ("## Contributor = " + "\"" + "Don Brutzman 
and Ray McClain" + "\""); 

xmlOutput.println ("## Originator = " + "\"" 4+ "Naval 


Postgraduate School" + "\""); 
xmlOutput.println ("## Data_Source 
Survey" 4. n\n ") > 


ny "\"" 4 “NOAA Seabeam 


xmlOutput.println ("## Data _Format = " + "\"" + "Surfer DSAA 
Export" + m\ uw) » 

xmlOutput.println ("## Datum = " + "\"" + "NAD83" 4 "\""); 

xmlOutput.println ("## Ellipsoid = "+ "\"" + "GRS 1980" 4+ 
WLW): os 

xmlOutput.printin ("## UTM_zone = "+ "\"" 4 


VyT0" 4+ wy) > 

xmlOutput.printlin ("## North _Bounding Coordinate_UITM 
+ uleftUTMN + "\""); 

xmlOutput.println ("## South_Bounding_ Coordinate_UTM = "+ "\"" 
+ lleftUTMN + "\""); 


no4y n\n n 


xmlOutput.println ("## West Bounding Coordinate UTM = " + "\"" 
+ uleftUTME + "\""); 
xmlOutput.println ("## East Bounding Coordinate_UTM = "+ "\"" 


+ 


urightUTME + "\""); 
xmlOutput.println ("## Northwest_Bounding Coordinate Latitude 
Woy n\un + uleftLat + m\un)y 
xmlOutput.println ("## Southwest_Bounding Coordinate Latitude 
Woy n\ un + lleftLat + n\n ") >; 
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xmlOutput.println ("## Northeast_Bounding Coordinate Latitude 
Bop NN Oe urignthar + Y\'t) > 

xmlOutput.println ("## Southeast_Bounding Coordinate Latitude 
Wc NO ee Pe ghekat. 2) ; 

xmlOutput.println ("## Northwest_Bounding Coordinate Longitude 
"4 "\"'" + uleftLong + "\""); 

xmlOutput.println ("## Southwest _Bounding Coordinate_Longitude 
mie oh\r" 4 LleftLong + "\""); 

xmlOutput.println ("## Northeast_Bounding Coordinate Longitude 
We TOW 4 Uaerghthong 4° UY"); 

xmlOutput.println ("## Southeast_Bounding Coordinate Longitude = 
"oy U\"t 4+ LrightLong + "\""); 

xmlOutput.println ("## maxDepth 


IN 


Wo4g i es us maxDepth + my) 


ymlOutput.println ("## minDepth = " + "\"" + minDepth + "\""); 

xmlOutput.println ("## postSpacing = " + "\"" + postSpacing + 
w\ nn) : 

xmlOutput.println (" </Tiles") ; 


// Create output stream to export VRML:. 

FileOutputStream vrmlOutputFile = new FileOutputStream 
(fileName) ; 

PrintStream vrmlOutput = new PrintStream (vrmlOutputFile) ; 


// Export VRML: 

vrmlOutput.println ("#VRML V2.0 utf£8"); 

vrmlOutput.println ("# Terrain Tile"); 

vrmlOutput.println ("# Autogenerated by CreateVRMLTerrain Program 
on 9/15/98") ; VIMLOUEDUL.orintin ("#"): 

vrmlOutput.printlin ("# " + fileName) ; 

vrmlOutput.println ("#"); 

vrmlOutput.println ("## Based on proposed VRML Metadata 
Convention of 9/1/98"); 

vrmlOutput.println ("## EXTERNPROTO Metadata [ "); 


vrmlOutput.println ("## field MFString xmlurl"); 

vrmlOutput.printlin ("## eventIn MFString set_xmlurl") ; 

vrmlOutput.println ("## eventOut MFString xmlurl_changed") ; 

vrmlOutput.println ("## eventIn SFString elementID") ; 

vrmlOutput.println ("## eventOut MFString elementIDs") ; 

vrmlOutput .println ("## eventOut SFString tagName") ; 

vrmlOutput.printlin ("## eventOut MFString attributeNames") ; 

vrmlOutput.println ("## eventOut MFString 
attributeValues") ; 

vrmlOutput.println ("## eventOut MFString childElements") ; 

vrmlOutput.println ("## eventOut MFString 
childElementTypes") ; 

vrmlOutput.println ("## ) "+ "\""™ + "l./../metadata.wrl" + 
cee 

vrmlOutput.println ("## DEF Tile Metadata {") ; 

vrmlOutput.println ("## xmlurl ["); 

vrmlOutput.println ("## ee NN Me Pm 


version='1.0'?>") ; 
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aS) 


vrmlOutput.printlin ("## 


vrmlOutput.println ("## 


Sanctuary Terrain Model'") ; 


vrmlOutput.println ("## 
vrmlOutput.printlin ("## 


'Monterey, California'") ; 


vrmlOutput.printlin ("## 
vrmlOutput.println ("## 
vrmlOutput.println ("## 


McClain'") ; 


vrmlOutput.println ("## 


School'"); 


uleft 


vrmlOutput .printlin ("## 
vrmlOutput.printin ("## 
vrmlOutput.println ("## 
vrmlOutput.printlin ("## 
vrmlOutput.printin ("## 
vrmlOutput.printlin ("## 
UTMN + LL Te 
vrmlOutput.println ("## 


lleftUTMN + "'"); 


uleft 


vrmlOutput.println ("## 
UIME + aL Te, 
vrmlOutput.println ("## 


urightUTME + "'"); 


Ut + 


Ut + 


vrmlOutput.printlin ("## 
uleftLat + "'"); 
vrmlOutput.printlin ("## 
lleftLat + "'"); 
vrmlOutput.printin ("## 
urightLat + "'"); 
vrmlOutput.printlin ("## 
lrightLat + "'"); 
vrmlOutput.printlin ("## 
uleftLong + "'"); 
vrmlOutput.printlin ("## 
lleftLong + "'"); 
vrmlOutput.printlin ("## 


urightLong + "'"); 
vrmlOutput.printlin ("## 
lrightLong + "'"); 


vrmlOutput.printlin ("## 
vrmlOutput.println ("## 
vrmlOutput.printlin ("## 
vrmlOutput.printin ("## 
+ xmlfileName +"\"") ; 

vrmlOutput.println ("## 
vrmlOutput.println ("## 


<Tile ID = '" + fileName + 
Title = 'Monterey Bay National Marine 


Subject = 'VRML Terrain Model'") ; 
Publication Place = 


Publication Date = '1998'"); 
Creator = 'Greg Leaver'"); 
Contributor = 'Don Brutzman and Ray 


Originator = 'Naval Postgraduate 


Data_Source = 'NOAA Seabeam Survey'") ; 
Data_Format = 'Surfer DSAA Export'") ; 
Datum = 'NAD83'"); 

Ellipsoid = 'GRS 80'"); 


UTM_zone = '10'"); 
North Bounding Coordinate _UTM = '" 4+ 
South Bounding Coordinate UTM = tM 4 
West_Bounding Coordinate UTM = '" + 
East_Bounding Coordinate UTM = '" + 


Northwest_Bounding Coordinate Latitude 
Southwest_Bounding Coordinate_Latitude 
Northeast_Bounding Coordinate Latitude 
Southeast_Bounding Coordinate_Latitude 
Northwest_Bounding Coordinate Longitude 
Southwest_Bounding_ Coordinate_Longitude 
Northeast_Bounding Coordinate _Longitude 


Southeast_Bounding Coordinate_Longitude 


maxDepth = 8M 4 maxDepth ee LS 1a 

minDepth = '" + minDepth + "'"); 

postSpacing = '" + postSpacing + "'"); 
</Tile>" a: een +h My n\n + 


ie Ia 
+t) 


vrmlOutput.println ("Group {"); 
vrmlOutput.printlin ("children ["); 


vrmlOutput.printlin (" 


Transform { "); 
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VrmlOutput:. printin (" translation " + xTransform +" 0" + 
zTransform) ; 
vrmlOutput.println (" children [ "); 


// Construct Navigation Marker: 


vrmlOutput.println (" DEF NavigationMarker Transform {" 
ie 

vrmlOutput.printlin (" bhoxSize 25 25°25 ")s; 

vrmlOutput.println (" translation " + 
(postSpacing* (xDimension-1)/2) + " "+ "25000" + " "4 
(postSpacing* (zDimension-1) /2)); 

VrmlLOutput.prantin..(" scale 400 400 400 "); 

vrmlOutput.println (" children [ "); 

vrmloutput.println ("_ LOD { "); 

vrmlOutput.printin (" range [200, 400, 600] "); 

vrmlOutput.println (" level [ "); 

vrmlOutput.println (" Group {"); 

vrmlOutput.printin (" Geni laren vi). 

vrmlOutput.println (" Anchor { "); 

vrmlOutput.println (" . ‘description "+ "\"" = "click 
on sphere to remove marker" + "\""); 

vrmlOutput.println (" Children Inliné {urd "74 
m\nn 4". ./,../Icons/spherearrows.wrl" + "\"" 4 " }"); 

vrmlOutput.println (" | aaa 

vrmlOutput .println (" Group { "); 

vrmlOutput.println (" children |--") ; 

vrmlOutput.printin (" DEF SphereMarker TouchSensor { }"); 

vrmlOutput.println (" Inline { url "+ "\"" + 
"../../Icons/sphere.wrl" + "\"" + " }"); 

vrmlOutput.println (" ia; 

vrmlOutput.println (" ee 

vrmlOutput.println (" Transform { "); 

vrmlOutput.println (" translation 20 0 0 "); 

vrmlOutput.printin (" children "); 

vrmlOutput.println (" Anchor { "); 

vrmlOutput.println (" Uy tr Ne ee 
viewpointName + "\""); 

vrmlOutput.println (" description " + "\"" +"East View 
from this location " + postSpacing + "m. resolution" +"\""); 

vrmlOutput.println (" children "); 

vrmlOutput.println (" Billboard { "); 

vrmlOutput.println (" axisOfRotation 0 1 0 
Yee 

vrmlOutput.println (" childrens"); 

vrmlOutput.println (" Shape { "); 

vrmlOutput.println (" appearance Appearance { 
ie 

vrmlOutput.printlin (" material Material 
{ ") > 

vrmlOutput.println (" emissiveColor 1.0 1.0 
1 0S 

vrmlOutput.println (" diffuseColor 0.0 0.0 
0.0") > 
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Ae ae + 


vrmlOutput. 
‘Printin: " 
sprintin {” 
~—printin (" 


vrmlOutput 
vrmlOutput 
vrmloOutput 
“ye ") : 

vrmlOutput 


FontStyle { "); 


vrmlOutput 


+ LS | ; 


vrmlOutput 


"MIDDLE" Sa lh + 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 


vrmlOutput. 
sprintin: (" 


vrmlOutput 


vrmlOutput. 
-printin <(" 
-printin ({" 
pprinein 
“prantin: (" 
spranein (" 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmloOutput 


Drintin {" 


.println (" 
sprintin {" 


“printin -(" 


ee i 


ee 

geometry Text { "); 
string Woy n\n + 
fontStyle 


style woo n\un + "BOLD" 


justify [" + ee + 


se ca w\ nn me "MIDDLE" Se +"J")> 


sprintin (" 
.printlin (" 
s—printin (" 
sprintin (* 


printin (" 


println -(" 


viewpointName + "\"") ; 
vrmlOutput.printin 


(" 


Size 8 "); 
ao 
Pe" les 
}"); 
1") 3 
") 


} "); 
Transform { "); 
translation 0 0 -20 "); 
children "); 

Anchor { "); 
url Woy orn + "nN" + 


description " + "\"" +"North View 


from this location " + postSpacing + "m resolution" + "\""); 


vrmlOutput.printin 
vrmlOutput.printin 
vrmlOutput.printin 
ap 
vrmlOutput.printin 
vrmlOutput.printin 
vrmlOutput.printin 
vrmlOutput.printiln 
vrmlOutput.printin 
0-42 On) 
vrmlOutput .printlin 
0.06.0 "): 
vrmlOutput.printin 
vrmlOutput.println 
vrmlOutput.printin 
vrmlOutput.printin 
w\nn) » 
vrmlOutput .printin 
“ae 
vrmlOutput.printin 
"BOLD" + Ue SLE Yr 
vrmlOutput.printin 
+ "MIDDLE" -ir\un + 1 + 
vrmlOutput.printin 
vrmlOutput.printlin 
vrmlOutput.printin 
vrmlOutput.printin 


(" 
(" 
c" 


(" 
(" 
(" 
(" 
(" 


(" 


children "); 
Billboard { "); 
axisOfRotation O01 0 


children "); 
Shape { "); 
appearance Appearance { "); 
material Material { "); 
emissiveColor 1.0 


GiffuseColor 0.0 


pee 
b ™)y 
geometry Text { "); 
string wo4 aL + MN 4 
fontStyle FontStyle { 
style wooy mun + 


justify [" a. ae 


ae + "MIDDLE" est +"j"); 


(" 
c" 
(" 
(" 


size 8 "); 


TI 


sprantin 
.println 
.printin 
.println 
.println 
.println 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput.printlin 
vrmlOutput.printlin 
viewpointName + "\""); 
vrmlOutput.printlin 


(™ 
(" 
& 
cy 
(" 
(" 
(" 
a 


Gu. 


| ae 

}o"); 
pels 
Transform { 
translation 
children ") 


a 
0 0 20 


Y 
é 


m3 


Anchor {°"); 


url’ 


description 


- n\un - "#S " i 


Moy a wt +"South View 


from this location " + postSpacing + "m resolution" + "\""); 


vrmlOutput.println 

vrmlOutput.printlin 

vrmlOutput.printlin 
ia) 

vrmlOutput.printlin 

vrmlOutput.printin 

vrmlOutput.printin 


vrmlOutput.printin 
Lene 
vrmlOutput.printlin 
Me) bas 
vrmlOutput.printlin 
We; 
vrmlOutput.printin 
vrmlOutput.printin 
vrmlOutput.printlin 
vrmlOutput.printin 
Wom 4 w\ nn) ; 
vrmlOutput.printin 


i.9 


0.0 


"); 
vrmlOutput .println 
+ w\ am) ; 
vrmlOutput.println 


(" 
(" 
(" 
(" 
cs 
(" 


(" 


GL 


(" 


"MIDDLE uw + t x i + " ; " + Ww x te | 


vrmlOutput.printlin 
vrmlOutput.printin 
vrmlOutput.println 
vrmlOutput .println 
vrmlOutput.println 
vrmlOutput.printlin 
vrmlOutput.println 
vrmlOutput.println 
vrmlOutput.println 
vrm2 Output. printin 
vrmlOutput.println 
vrmlOutput.printlin 
viewpointName + "\""); 
vrmlOutput.printin 


(" 
(Cs, 
(" 
(" 
(" 
(" 
cy 
(" 
au 
(" 
(" 
(" 


(" 


children "); 


Billboard { "); 


Shape 


+ "MIDDLE" $n\un +") 


| a a 
ea) a 


} jee 

Transform { 
translation 
children ") 


axisOfRotation 0 1 0 


children 
ae e: 
appearance Appearance { 


i 


material Material 
emissiveColor 1.01.0 


GdiffuseColor 0.0 0.0 


}"); 

Pp ote 

geometry Text { "); 
string Woy w\ wen fe 


fontStyle FontStyle { 
style Woy Wr) + "BOLD" 


justify [" + oer 4 
i 
size 8 "); 
ee 
} "); 


oe a 
Wr Je 


-20 0 0 


& 


he 


Anchor { "); 
url wos m\ wie + "SW" + 


description 


my nine + "West View 


from this location " + postSpacing + "m resolution" +"\""); 


vrmlOutput.println 
vrmlOutput.printlin 


co 
(" 


children "); 


Billboard { "); 


vrmlOutput.println 
ae e 

vrmlOutput.printlin 

vrmlOutput.println 

vrmlOutput.printin 


vrmlOutput.printin 


vrmlOutput.println 
120“) = 
vrmlOutput.printlin 
050%) 3 
vrmlOutput.printlin 
vrmlOutput.printlin 
vrmlOutput.printlin 
vrmlOutput.printin 
nyo eee 
vrmlOutput.printin 
FontStyle { "); 
vrmlOutput.println 
+ WLM) 
vrmlOutput.println 


(" 


(" 


(" 


at MIDDLE tt + wt \ te + te ; w + a \ tt tt 


vrmlOutput.printin 
vrmlOutput.printlin 
vrmlOutput.println 
vrmlOutput.printlin 
vrmlOutput.printin 
vrmlOutput .println 
vrmlOutput.println 
vrmlOutput.printlin 
vrmlOutput.printin 
vrmlOutput.println 
vrmlOutput.printin 
vrmlOutput.println 
vrmlOutput.printin 
vrmlOutput.printlin 
vrmlOutput .printin 
w)s 
vrmlOutput.println 
vrmlOutput.printin 
ds Oo) 
vrmlOutput .printin 
0.0 "); 
vrmlOutput.printin 
vrmlOutput.printlin 
vrmlOutput.printin 
vrmlOutput.printin 
northing + "N" 4+ "\"" 4 
vrmlOutput.println 
") > 
vrmlOutput .printin 
+ "MIDDLB" n\n + mon + 


(" 
(" 
(" 
(™ 
(" 
(" 
Gy 
(" 
(" 
(" 
(" 
(" 
(" 
(" 
(" 


(" 
cm 


(* 


(" 
au 
(" 
(" 


oo 


(" 


axisOfRotation 01 0 
Children "); 
Shape { "); 

appearance Appearance { 
material Material 

emissiveColor 1.0 1.0 

diffuseColor 0.0 0.0 
} "); 

} "); 

geometry Text { "); 
string tt + ee + 
fontStyle 


style moy SL ea + "BOLD" 


justify [" + mt + 


+ "MIDDLE" — 47"). 


size 8 "); 
: Oe 
ls ee 

} ); 

ae 

} "); 

Po"); 

Transform {"); 
translation 018 0"); 
children "); 

Billboard { "); 
axisOfRotation 010 "); 
children "); 

Shape { "); 

appearance Appearance { 


material Material { "); 
emissiveColor 1.0 1.0 


adiffuseColor 0.0 0.0 


} "ys 
es 
geometry Text { "); 
string [" - w\ nt zs 


Poy + n\n + easting + " BM yg w\ wn +") "); 


fontStyle FontStyle { 


justify [" + he 


" \ a tt + "MIDDLE i] + w \ wt tt + w] " ) ;: 


vrmlOutput 
vrmlOutput 
vrmlOutput 


vrmlOutput. 


vrmlOutput 
vrmloOutput 
vrmlOutput 


vrmlOutput. 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 


sprintin 
.printin 
~.printin 
printin 
.printin 
.printin 
{pEIntin 
printin 
._printin 
.printin 
.printin 
.printin 


(" 
(" 
c" 
(" 
(" 
(™ 
ee 
(" 
(* 
(" 
cu 
(" 


box to remove marker" + "\" 
vrmlOutput.println (" 


+"../../Icons/boxarrows.wrl" + "\"" 


pines 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 


vrmlOutput 


._printin 
.printin 
.printin 
._printin 


MOrinein 


(" 
Gh 
eu. 
i 


+"/../../Icons/box.wrl" + " 


vrmlOutput 
vrmlOutput 


vrmlOutput. 


vrmlOutput 


vrmlOutput. 


vrmloOutput 


vrmlOutput. 


vrmlOutput 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 


vrmlOutput. 


vrmlOutput 
vrmlOutput 


.printin 
-printin 
printin 
sprintin 
printin 
~prantin 
printin 
.printin 


../Icons/box.wrl" + 


sprantin 
.printin 
<printin 
<_priantin 
printlin 
.printin 


-printin 


// Construct Topography: 


vrmlOutput 
vrmlOutput 


vrmlOutput. 


vrmlOutput 
vrmloOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 


[pele in 
a, opaphayead tna 
printlin 
.printin 
.printin 
,prantin 
.println 
.println 


gridName.substring (0,38) 


vrmlOutput 
vrmlOutput 
vrmlOutput 
vrmlOutput 


._printin 
sprantin 
.printin 
._printin 


Po: 


J 


i 


a 
Group {"); 
children ["); 
Anchor { "); 
description “ + "\"" « "click on 


Le) 


children Inline { url " + "\"" 


} 


+" "); 


"3 


Group { "); 


children [ 


eo 


DEF BoxMarker TouchSensor { 


cn Inline: {suri "Saw 
\ue ~ " poe: 

cs | ata 

(" }"); 

(3); 

(" } "ys 

(> {Group e{ wv"); 

(es Sehaldrens [oy 

ou USE BoxMarker "); 

ie Thlanes (card eer 

n\un ou Oe 

eels tun) ee 

(" } "); 

("Group { }"); 

ae) | 1 

(" }"); 

(" 1"); 

(" } "); 


(" 
ca 
(" 
(" 
(" 
Ok 
(" 
(" 
Br 

O 
cu 
(" 
(" 


DEF Topography Transform {" ); 
scale 11 1"); 
children [ "); 
Shape { "); 

appearance Appearance {") ; 
material Material { }"); 
texture ImageTexture {") ; 


GD 2 Ae Ws / Images/ Sot 


Ws] oze id + Be ); 
poe 


ee: 


geometry ElevationGrid {") ; 
xDimension " + xDimension) ; 
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vrmlOutput.printlin (" zDimension " + zDimension) ; 
vrmlOutput.printin (" xSpacing " + postSpacing) ; 
vrmlOutput.printlin (" zSpacing " + postSpacing) ; 
vrmlOutput.println (" solid FALSE") ; 
vrmlOutput.printlin (" creaseAngle 0.785"); 
vrmlOutput.printlin (" height ["); 
for (j = 0; j <= (zDimension -1); j++) { 

for (i = 0; i <= (xDimension-1); i++) { 


} 


vrmlOutput.print (vrmlArray [j] 


fae 


vrmlOutput.println (); 


} 


vrmlOutput.println (" ko Ie 

vrmlOutput.println (" 1m). 5 

vrmlOutput.println (" Nusa 

vrmlOutput.println (" | aa? a 

vrmlOutput.printlin (" PG 

vrmlOutput.println (" ae 

vrmlOutput.printin ("_ }"); 

vrmlOutput.println ("]"); 

vrmlOutput.println ("}"); 

vrmlOutput.println ("DEF TimeMarker TimeSensor { ") ; 

vrmlOutput.printlin (" cycleInterval 1.0 "); 

vrmlOutput.printin (" loop FALSE "); 

vrmlOutput.printlin (" startTime 0:.0:..")> 

vrmlOutput.println (" stopTime tO 

vrmlOutput.printin ("}, "); 

vrmlOutput.printlin ("DEF ScaleMarker PositionInterpolator { "); 

vrmlOutput.printin (" key [0.0 2.01]: 2%): 

vrmlOutput.printin (" keyValue [0.01 0.01 0.01, 0.01 0.01 0.01) 
SG 

VrEmMLOUtEPue.printin {(*) “)-; 

vrmlOutput.printlin ("ROUTE BoxMarker.touchTime TO 
TimeMarker.set_startTime") ; 

vrmlOutput.println ("ROUTE SphereMarker.touchTime TO 
TimeMarker.set_startTime") ; 

vrmlOutput.println ("ROUTE TimeMarker.fraction_changed TO 
ScaleMarker.set_fraction") ; 

vrmlOutput.printin ("ROUTE ScaleMarker.value_changed TO 


NavigationMarker.set scale") ; 


// Construct Viewpoint looking North: 


viewpointOutput.println (" 
viewpointOutput.printin (" 
viewpointOutput.printin (" 
" 37500 " + ztreeTranslation) ; 
viewpointOutput.printlin (" 
viewpointOutput.printlin (" 
Viewpoint {"); 
viewpointOutput.println (" 
viewpointOutput.printlin (" 
viewpointOutput.printlin (" 


Transform {"); 
rotation 010 0"); 
translation " + xtreeTranslation + 


children"); 
DEF N_" + viewpointName + " 


orientation 10 0 -.35"); 


}"); 
7); 
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// Construct Viewpoint looking South: 


viewpointOutput.printlin (" 
viewpointOutput.printin (" 
viewpointOutput.printin (" 
" 37500 " + ztreeTranslation) ; 
viewpointOutput.println (" 
viewpointOutput.printin (" 
Viewpoint {"); 
viewpointOutput.println (" 
viewpointOutput.println (" 
viewpointOutput.println (" 


Transform {"); 


rotation 01 0 3.14"); 
translation " + xtreeTranslation + 


children") ; 


// Construct Viewpoint looking East: 


viewpointOutput.printlin (" 
viewpointOutput.printlin (" 
viewpointOutput.printlin (" 
" 37500 " + ztreeTranslation) ; 
viewpointOutput.println (" 
viewpointOutput.printlin (" 
Viewpoint {"); 
viewpointOutput.println (" 
viewpointOutput.println (" 
viewpointOutput.printin (" 


DEF S_" + viewpointName + " 
orientation 10 0 -.35"); 


Ge 
p ye 


Transform {"); 


rotation 01 0 -1.57"); 
translation " + xtreeTranslation + 


children") ; 


// Construct Viewpoint looking West: 


viewpointOutput.println (" 
viewpointOutput.println (" 
viewpointOutput.println (" 
" 37500 " + ztreeTranslation) ; 
viewpointOutput.println (" 
viewpointOutput.println (" 
Viewpoint {"); 
viewpointOutput.println (" 
viewpointOutput.printin (" 
viewpointOutput.println (" 


vrmlOutputFile.close( ); 


lastxDimension = xDimension; 
lastxTransform = xTransform; 


lastzDimension [xCounter - 


lastzTransform [xCounter - 1] 


} 


lastxTransform 
lastxDimension 


0; 
1; 


} 


viewpointOutputFile.close ( 


} 


DEF E_" + viewpointName + " 
orientation 10 0 -.35"); 


Le 
ee 


Transform {"); 


rotation 0 101.57"); 


translation " + 


xtreeTranslation + 


children"); 
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DEF W_" + viewpointName + " 


orientation 100 -.35"); 
| Dy 
NLD) 


zDimension; 
zTransform; 


APPENDIX D: CREATEVRMLTREE JAVA PROGRAM 


// 


TTC TCcCcLcecCeSeASeSSAeSAEASEEAAAASAEARSASAASALARARARARARARRA DES ED ee eee ee ee ee ee ee ee ee ee oe ee ee 
// Script Name: Createl000mVRMLTree. java 


// Description: Create a VRML terrain tree at 1000m post-spacing 
resolution 


is 

// Author: R. Greg Leaver 

// Advisor: Don Brutzman 

// 

// Revised: 1 September 98 

// 

// Notes: Need one class for each post-spacing 
as 

// 

eC ReCReeReEeECeSERSERAEEERAEAEAASESAESAAAASASREALAARARABRARRRRRRRRERRERER DE SD De ee ee ee eo 
Vy 


RMR KKK KKK KKK KKK EEE KEKE KEKE KEKE KEREEEEKEEKEKEEEK EEK KEEKKEEEKEKEEKSE 


import java.io.*; 


public class createl000mVRMLtree { 
public static void main (String argv [ ]) throws IOException { 


// Input stream to get 500m gridded data files to create children in 
tree: 

FileInputStream dataSetFile = new FileInputStream 
(*500mMGriagSet. exe”); 

StreamTokenizer dataSetTokens = new StreamTokenizer 
(dataSetFile) ; 


// Input stream to get 1000m parent centers: 
FileInputStream treeSetFile = new FileInputStream 
("1000mParentCenters.txt"); 
StreamTokenizer treeSetTokens = new StreamTokenizer 
(treeSetFile) ; 


// Construct and initialize array: 
String childArray [] = new String [16]; 
for (int i = 0; i <=15; i++) { 
dataSetTokens.nextToken( ); 
childArray [i] = dataSetTokens.sval; 


} 


// Make QuadLOD children: 
String child1, child2, child3, child4, parent, parentCenter; 
int n = 4; 
for (int i = 1; i <=4; i++) { 
childl = (childArray [n]).substring(0,29) + ".seabeam.wrl"; 


qi 


child2 = (childArray [n +1]).substring(0,29) + 
".seabeam.wrl"; 


child3 = (childArray [n-3]).substring(0,29) + 
" seabeam.wrl"; 
child4 = (childArray [n-4]).substring(0,29) + 


". seabeam.wrl"; 

parent = childl.substring(0,16) + 
".070.051.1000.seabeam.wrl"; 

if (i == 1 || i == 3) 


// Obtain parentCenter from file: 
treeSetTokens.nextToken( ) ; 
parentCenter = treeSetTokens.sval; 


// Create QuadLOd tree EXTERNPROTOS 
String treeName; 
treeName = childl.substring(0,16) + 
"070205 bx OOG se ree owrl'-; 
FileOutputStream vrmlOutputFile = new FileOutputStream 
(treeName) ; 
PrintStream vrmlOutput = new PrintStream (vrmlOutputFile) ; 
VEMLOULDUL. printin ("$VRML V2.0 ucts"). 
VrmlOuGpUut aprintin (+ terrain’ tree”). 
VremlOuteuL.-prantiln (ye) 
vrmlOutput.println("EXTERNPROTO QuadLOD [ "); 


VEMLOUEDUL- print Ln (’ta2ela MFString parentUrl ") ; 
vrinlOuLpUt.println(Yfreld MESEring ¢chilalurl "); 
VrmLOUtpue.prantin(”fteld MFPS€ring chira2url ")-; 
vrmlOutput.printin ("field MPStEring childad3sUrl "): 
vrmlOutput.printin ("field MEStrang child4uzle |) 
vrmlOut put .printin ("field SFVec3£ parentCenter ") ; 
vrmlOutput.printin ("field SFVec3£ parentSize "); 
Vr LOUE DUE pring int “field SFVec3£ switchSize "); 
vrmlOutput .printin ("eventOut MFNode chaldren: ")- 
vrmlOutput- print in ("tield SFBool enabled "); 
vrmlOutput.println("eventin SFBool set_enabled "); 
vrmlOutput.printin ("eventoOut SFBool enabled changed 


Ne 
VEMlOuEpUL pEeInt in (') “epee 
vo oa QUaadheD- wels#OuacloD. 0 th!) 
VEMlLOur mae pratt) 
VrmM_LOUtpuUE printin ("Group <4 "); 


VimlOuUCpUL. printin(" Chaldrena|ie). 

vyremlOut put prime) nat” WorldInfo { title " + "\"" 4 "Tree 
World for QuadLOD PROTO" + "\"" 4"}u); 

VrmMlOut put. pram lr (% QuadLOD { "); 

VIMLOutDUE. prant im (" ParentUrl "4 ir 4 


"1000m/Tiles/" + parent + "\""); 
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Princ” 
as We ae ee 
Drie lint" 
ca Be Le oe 


oOb2 ine Par 


es n\n). 


spranein 


4 n\n). 
Printin(” 


sorintln(” 
sorantin (” 
fOrintan | | 


7DOvincla 
fprintin (jo); 


} 
| 


vrmlOutputFile.close( ); 


VIMLOUEDUE . 
"SoOm/Tiles/" + childl 
vrmlOutput. 
"500m/Tiles/" + child2 
VrMmLOULpDUL 
"Soom/Tiles/" + child3 
vrmlOutput 
"SOOm/Tiles/" + child4 
vrmlOutput. 
parentCenter) ; 
vrmlOutput 
130000 "); 
vrmlOutput 
130000 "); 
vrmlOutput 
vrmlOutput 
vrmlOutput 
} 
} 
} 
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ee 
J ae 


GhilaluUrina"” = w\n i 


ras a WU 8 § ge a 
chi ldsuri + "hn 
chalasurie! + eye 
parentCenter " + 

parentSize 76000 
SwitchSize 76000 
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APPENDIX E: EXAMPLE VRML TERRAIN TILE FILE STRUCTURE 


#VRML V2.0 utf8 

# Terrain Tile 

# Autogenerated by CreateVRMLTerrain Program on 9/15/98 
# Available at www.stl.nps.navy.mil/~auv/leaver 


# 

# N353610.W1232629.070.051.1000.seabeam.wrl 

é 

## Based on proposed VRML Metadata Convention of 9/1/98 

## EXTERNPROTO Metadata [ 

## field MFString xmlurl 

HH eventIn MFString set_xmlurl 

## eventOut MFString xmlurl_changed 

rH eventIn SFString elementID 

## eventOut MFString elementIDs 

ae eventOut SFString tagName 

ah. eventOut MFString attributeNames 

## eventOut MFString attributeValues 

## eventOut MFString childElements 

## eventOut MFString childElementTypes 

## ] "../../metadata.wrl" 

## DEF Tile Metadata { 

## xmlurl [ 

HE "<?xml version='1.0'?> 

## <Tile ID = 'N353610.W1232629.070.051.1000.seabeam.wrl'> 
## Title = 'Monterey Bay National Marine Sanctuary Terrain 
Model' 

## Subject = 'VRML Terrain Model' 

## Publication Place = 'Monterey, California' 
## Publication_Date = '1998' 

## Creator = 'Greg Leaver' 

## Contributor = 'Don Brutzman and Ray McClain' 

## Originator = 'Naval Postgraduate School' 

th Data_Source = 'NOAA Seabeam Survey' 

## Data_Format = 'Surfer DSAA Export' 

HE Datum = 'NAD83' 

Ht Ellipsoid = 'GRS 1980' 

## UTM_zone = '10'! 

## North Bounding Coordinate_UTM = '4070000' 

HE South_Bounding Coordinate_UTM = '3940000' 

## West_Bounding Coordinate UTM = ' 46000' 

## East_Bounding Coordinate UTM = ' 53600' 

HH Northwest_Bounding Coordinate Latitude = 'N36d46m2' 
HH Southwest _Bounding Coordinate Latitude = 'N35d36m1' 
HH Northeast_Bounding Coordinate Latitude = 'N36d46m3' 
## Southeast_Bounding Coordinate_Latitude = 'N35d36ml1' 
BE Northwest_Bounding Coordinate Longitude = 'W123d26m5S' 
#¢ Southwest_Bounding Coordinate Longitude = 'W123d26m2' 
aE Northeast_Bounding Coordinate_Longitude = 'W122d35m4' 
He Southeast_Bounding_ Coordinate_Longitude = 'W122d36m0' 
#$# maxDepth = '-1449.41' 

## minDepth = '-3811.36' 


8] 


## postSpacing = '1000' 


## </Tile>", "../N353610.W1232629.070.051.1000.seabeam. xml" 
# # ] 

## } 

Group { 

children [ 


Transform { 
translation 0 0 130000 
children [ 
DEF NavigationMarker Transform { 
bboxSize 25 25 25 
translation 38000 25000 65000 
scale 400 400 400 
children [ 
LOD { 
range [200, 400, 600] 
level [ 
Group { 
children [ 
Anchor { 
description "click on sphere to remove marker" 
children Inline { url 
"_./../Icons/spherearrows.wrl" } 


Group { 
children [ 
DEF SphereMarker TouchSensor { } 
Inline { url "../../Icons/sphere.wrl" } 
] 
} 


Transform { 
translation 20 0 0 
children 
Anchor { 
url "#E 353610 1232629 070 051 1000" 
description "East View from this location 
1000m. resolution" 
children 
Billboard { 
axisOfRotation 0 1 0 
children 
Shape { 
appearance Appearance { 
material Material { 
emissiveColor 1.0 1.0 


a Ue 8, 
diffuseColor 0.0 0.0 
0.0 
} 
} 
geometry Text { 
Strings se" 


fontStyle FontStyle { 
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style "BOLD" 
justify 


["MIDDLE", "MIDDLE" ] 
size 8 


} 
} 
Transform { 
translation 0 0 -20 
children 
Anchor { 


url "#N_ 353610 1232629 070 051 1000" 
description "North View from this location 
1000m resolution" 
children 
Billboard { 
axisOfRotation 0 1 0 
children 
Shape { 
appearance Appearance { 
material Material { 


emissiveColor 1.0 1.01.0 
qadiffuseColor 0.0 0.0 0.0 
} 
} 
geometry Text { 
string "N" 
fontStyle FontStyle { 
style "BOLD" 
justify ["MIDDLE", "MIDDLE" ] 
size 8 
} 
} 


} 
Transform { 
translation 0 0 20 
children 
Anchor { 
url "#S_ 353610 1232629 070 051 1000" 
description "South View from this location 
1000m resolution" 
children 
Billboard { 
axisOfRotation 0 1 0 
children 
Shape { 
appearance Appearance { 
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material Material { 
emissiveColor 1.0 1.0 


1.0 
diffuseColor 0.0 0.0 
0.0 
} 
} 
geometry Text { 
String =sS" 
fontStyle FontStyle { 
style "BOLD" 
justify 
[("MIDDLE", "MIDDLE" ] 
size 8 
} 


} 
} 
Transform { 
translation -20 0 0 
children 
Anchor { 
url "#W_353610 1232629 070 051 1000" 
description "West View from this location 1000m 


resolution" 
children 
Billboard { 
axisOfRotation 0 1 0 
children 
Shape { 
appearance Appearance { 
material Material { 
emissiveColor 1.0 1.0 
a0 
@iffuseColor 0.0 0.0 
0.0 
} 
} 
geometry Text { 
string "Ww" 
fontStyle FontStyle { 
style "BOLD" 
justify 
[("MIDDLE", "MIDDLE" ] 
size 8 
} 
} 
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} 


} 


Transform { 
translation 0 18 0 
children 
Billboard { 
axisOfRotation 0 1 0 
children 
Shape { 
appearance Appearance { 
material Material { 
emissiveColor 1.01.01.0 
diffuseColor 0.0 0.0 0.0 
; } 
geometry Text { 
string ["4005000 N", "498000 E"] 
fontStyle FontStyle { 
justify ["MIDDLE", "MIDDLE"] 
size 6 


} 


} 


Group { 
children [ 
Anchor { 
description "click on box to remove marker" 
children Inline { url "../../Icons/boxarrows.wrl" } 
} 
Group { 
children [ 
DEF BoxMarker TouchSensor { } 
Inline { url "/../../Icons/box.wrl" } 


Group { 
children [ 


USE BoxMarker 
inline { url “.;/../l¢cons/bex.wrl" } 


Group { } 


DEF Topography Transform { 
scale 111 
children [ 
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Shape { 


appearance Appearance { 
material Material { } 
texture ImageTexture { 


url 


"_./Images/N353610.W1232629.070.051.1000.seabeam. jpg" 


} 
} 


geometry ElevationGrid { 


xDimension 77 

zDimension 131 
xSpacing 1000 

zSpacing 1000 

solid FALSE 


creaseAngle 0. 

height [ 
-3519 -3511 -3503 -3493 -3484 
-3415 -3400 -3386 -3371 -3355 
-3245 -3241 -3230 -3214 -3200 
-3071 -3077 -3048 -3019 -2995 
-2746 -2646 -2615 -2591 -2597 
-2464 -2426 -2406 -2362 -2325 
-3801 -3804 -3806 -3807 -3806 
-3692 -3649 -3613 -3571 -3510 
-2765 -2655 -2776 -2991 -3111 
-3230 -3256 -3284 -3301 -3341 

] 

! 
] 

] 
} 


DEF TimeMarker TimeSensor { 
cycleInterval 1.0 
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-3476 
=3343 
=3175 
=2975 


-2601 
-2270 
-3805 
-3426 
=3192 


-3469 
=3332 
-3158 
=2959 


-2628 
-2244 
-3806 
=3333 
=3193 


-3464 
-3314 
-3145 
=-2951 


-2605 
-2226 
-3807 
-3295 
=5170 


0.0190 .010;01) 


loop FALSE 
startTime 0.0 
stopTime 1.0 
}. 
DEF ScaleMarker PositionInterpolator { 
key [0.0 1.0] 
keyValue [0.01 0.01 0.01, 
} 


ROUTE BoxMarker.touchTime 
ROUTE SphereMarker.touchTime 


ROUTE TimeMarker.fraction_changed 


TO TimeMarker.set_startTime 


-3453 
=3293 
=3093 
=2945 


-2558 
-2194 
-3809 
-3281 
-3162 


-3445 
=3272 
-3042 
S2937 


-2506 
-2176 
-3797 
=3155 
-3146 


- 3438 
-3260 
-3041 
=2902 


=Zo3 5 
=2155 
=3769 
-3104 
-3146 


TO TimeMarker.set_startTime 


TO ScaleMarker.set_fraction 
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-3430 
-3248 
=30>> 
=23029 


-2506 
-2167 
-3734 
=2962 
=3196 


ROUTE ScaleMarker.value_ changed TO NavigationMarker.set_ scale 
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APPENDIX F: EXAMPLE VRML TERRAIN TILE SCENE GRAPH 
File N353610.W1232629.070.051.1000.seabeam.wrl 


=== World Structure === 


World 

| 

+-===-Group 

| | 
+---Transform 


+---DEF NavigationMarker 


+---Transform 


| 

| 

| 

| 

| | 

| | 

| | +---LOD 

| | | 

| | +---Group 

| | — 

| | | +---Anchor 

| | eee 

| | | | +---Inline 

| | || 

| | | +~--Group 

| | a ee 

| | | | +---DEF SphereMarker 
| | a) eee ere! 

| | | | | +---TouchSensor 
| | er en 

| | | | +---Inline 

| | en 

| | | +---Transform 

| | ar 

| | | | +---Anchor 

| | en | 

| | | | +=~-Billboard 

| | || | 

| | | | +---Shape 

| | el | 

| | | | +~---Appearance 
| | | | | | 

| | | | | +---Material 
| | | | | 

| | | | +---Text 
| | | | | 

| | | | +-~-~-FontStyle 
| | ee 

| | | +---Transform 

| | ee 

| | | | +-~-Anchor 

| | | | 
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eee 
——— i ll 


— 2 n,n a a a i a ee! ee 
ee ns —==— = a a oe 


ems ce mc eS 


+---Billboard 


+---Shape 


+---Appearance 


| +---Material 


== Tex e 


+---FontStyle 


---Transform 
+---Anchor 
+---Billboard 
| 
+---Shape 
+---Appearance 
| +---Material 
+---Text 
+---FontStyle 
---Transform 
| 
+---Anchor 
+---Billboard 
+---Shape 
+---Appearance 


| +---Material 


+---Text 


+---FontStyle 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


---Transform 


+---Billboard 


+---Shape 
| 
oi Deal alee 
| 
| +---Material 
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+---Text 


+---FontStyle 


| | 

| | 

| | 

| | 

| | 

| +---Group 

| te 

| | +---Anchor 

| | 6 

| | | +---Inline 

| | | 

| | +---Group 

| | | 

| | +---DEF BoxMarker 
| | en 

| | | +---TouchSensor 
| | | 

| | +---Inline 

| | 

| +---Group 

| ee 

| | +---USE BoxMarker 

| (en eae 

| | | +---TouchSensor 
| ir 

| | +---Inline 

| | 

| +---Group 

| 

+ 


---DEF Topography 


+---Transform 


+---Shape 


+=>-fhppearance 


+---Material 


| 
| +---ImageTexture 
nh re 
---DEF TimeMarker 

ae 
---DEF ScaleMarker 

| 


+---Positioninterpolator 


---ROUTE BoxMarker.touchTime TO TimeMarker.set_ startTime 
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+---ROUTE SphereMarker.touchTime TO TimeMarker.set startTime 
+---ROUTE TimeMarker.fraction_changed TO ScaleMarker.set_fraction 


+---ROUTE ScaleMarker.value_changed TO NavigationMarker.set_ scale 
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APPENDIX G: EXAMPLE XML FILE 


File: N364630.W1223547.070.051.1000.seabeam.wrl 


## <?xml version= "1.0"?> 
## <Tile ID = "N364630.W1223547.070.051.1000.seabeam.wrl"> 
## Title = "Monterey Bay National Marine Sanctuary Terrain 
Model" 
## Subject = "VRML Terrain Model" 
## Publication Place = "Monterey, California" 
## Publication Date = “1993" 
## Creator = "Greg Leaver" 
## Contributor = "Don Brutzman and Ray McClain" 
## Originator = "Naval Postgraduate School" 
## Data_Source = "NOAA Seabeam Survey" 
## Data_Format = "Surfer DSAA Export" 
aft Datum = "NAD83" 
sH Ellipsoid = "GRS 1980" 
ae UTM zone = "10" 
## North Bounding Coordinate _UTM = "4200000" 
## South Bounding Coordinate UTM = "4070000" 
## West Bounding Coordinate_UTM = "536000" 
## East_Bounding_Coordinate_UTM = "612000" 
## Northwest _Bounding Coordinate Latitude = "N37d56m4" 
## Southwest Bounding Coordinate_Latitude = "N36d46m3" 
## Northeast _Bounding Coordinate_Latitude = "N37d56m2" 
# # Southeast Bounding Coordinate Latitude = "N36d46m0" 
ah Northwest Bounding _Coordinate_Longitude = "W122d35m2" 
## Southwest Bounding Coordinate_Longitude = "W122d35m4" 
ah Northeast Bounding Coordinate Longitude = "W121d43m3" 
## Southeast Bounding _Coordinate_Longitude = "W121d44m4" 
## maxDepth = "2.06128" 
HE minDepthn = "-2257.6" 
## postSpacing = "1000" 
</Tile> 


APPENDIX H: EXAMPLE VRML TERRAIN TREE FILE STRUCTURE 


#VRML 
# Terr 
# Auto 
# N353 
# Avai 
# 


V2.0 utf8 

ain Tree 

generated by CreateVRMLTree Program on 9/15/98 
610.W1232629.070.051.1000.tree.wrl 

lable at www.stl.nps.navy.mil/~auv/leaver 


EXTERNPROTO QuadLoOD [ 


field 
field 
field 
field 
field 
field 
field 
field 
evento 
field 
eventl 
evento 
] 
"http: 


Group 


MFString parentUrl 
MFString childl1Url 
MFString child2Url 
MFString child3Url 
MFString child4Url 
SFVec3£ parentCenter 
SFVec3£ parentSize 
SFVec3£ switchSize 

ut MFNode children 
SFBool enabled 

n SFBool set enabled 

We SFBool enabled changed 


//www.stl.nps.navy.mil/leaver/MBNMSterrain/QuadLOD.wrl#QuadLOD" ] 


{ 


children [ 
Worldinfo { title "Tree World for QuadLOD PROTO" } 
QuadLOD { 


parentUrl, [http://www.stl.nps.navy.mil/leaver/MBNMSterrain/1000m/ 


Tiles/N353610 .W1232629.070.051.1000.seabeam.wrl"] 


["http: 
232029. 


["http: 
230119. 


{"http: 
230120. 


L7RtEp: 
232641. 


childl1url 
//waw.stl.nps.navy.mil/leaver/MBNMSterrain/500m/Tiles/N353610.W1 
035.025.0500.seabeam.wrl"] 

child2url 
//wew.stl.nps.navy.mil/leaver/MBNMSterrain/500m/Tiles/N353613.W1 
035.025.0500.seabeam.wrl"] 

child3Url 
//www.stl.nps.navy.mil/leaver/MBNMSterrain/500m/Tiles/N361123.W1 
035.025.0500.seabeam.wrl"] 

child4Url 
//waww.stl.nps.navy.mil/leaver/MBNMSterrain/500m/Tiles/N361120.W1 
035.025.0500.seabeam.wrl"] 

parentSize 76000 50000 130000 

switchSize 76000 50000 130000 
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APPENDIX I: EXAMPLE VRML TERRAIN TREE SCENE GRAPH 


File N353610.W1232629.070.051.1000.tree.wrl 
=== World Structure === 


World 


| 


+---EXTERNPROTO QuadLOD 


+= ==GYrolup 


| 


+~--WorldInfo 


+---QuadLOD 
=== Scene Grapn-=== 


EXTERNPROTO QuadLOD 


World 


+ =< =Group 


| 


+---WorldInfo 


| 


+-~--QuadLOD 


a7 
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Monterey Bay Aquarium Research Institute (MBARI) 
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SRI International 
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Lockheed Martin Technical Services 

US EPA Scientific Visualization Center 
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Seamless Solutions, Inc. 
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Moss Landing Marine Laboratories 
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